Ask almost any South African organisation whether it complies with the Protection of Personal Information Act and someone will send you a link to the privacy policy. It is usually well written. It has been reviewed by a lawyer, approved by a committee and published on the website. It says the organisation keeps information only as long as necessary, shares it only with service providers under contract, protects it with appropriate safeguards and lets people ask what is held about them.
Then ask a different question: where, in the systems, does each of those sentences actually happen? Which job deletes the call recordings after twelve months? Which contract clause binds the outsourced collections agency? Which log shows that the access review ran last quarter? The room goes quiet, because the policy was written by one group of people and the systems were built by another, and nobody joined the two.
CloudNala's view is that a privacy policy is a promise, a privacy control is the mechanism that keeps the promise, and evidence is the record that proves it was kept. POPIA is satisfied by the second and third, not by the first. The policy still matters. It is how you tell people what you do. But on its own it describes intentions, and the Act regulates processing.
This series is general information about running privacy controls in production systems, not legal advice. It summarises the Protection of Personal Information Act for a technical and business audience; read the primary text and take advice from your information officer and a qualified legal practitioner before relying on any interpretation.
This is Part 1 of POPIA in Production, a six-part series for the engineers, architects, data teams and managers who run the systems personal information flows through. The AI and POPIA in Plain Language series explains what the law says about where AI can process data. This series is about the machinery: lawful basis as a design input, retention as a deletion pipeline, access requests as a system test, incident classification decided in advance, and governance after an AI feature fails.
Amanzi Credit is fictional, and its systems and figures are illustrative. Amanzi is a Gqeberha store-card and personal-loan lender with about 180,000 customers, a mobile app, a call centre, a CRM, a core loan system, a data warehouse and three outsourced operators: a collections agency, a statement-printing house and a cloud telephony provider. Last year it added an AI assistant that summarises each call into a note for the CRM. Its privacy policy runs to 14 pages.
Three different things called "privacy"
When people at Amanzi said "we have privacy covered", they meant one of three things, and they rarely noticed which.
The promise. A statement to customers about what Amanzi does: "we keep call recordings for 12 months." It lives in the policy, the app's consent screens and the call-centre script.
The control. The mechanism that makes the promise true whether or not anyone remembers it: a scheduled job in the telephony platform that deletes recordings on day 365. Controls are technical (a job, a filter, a permission) or organisational (a contract clause, a review, a sign-off), but they are always specific enough that you can point at them.
The evidence. The record that the control ran and worked: the monthly job log showing how many recordings were deleted and the age of the oldest one remaining.
The promise without a control is a hope. The control without evidence is an assumption. Only the three together let Amanzi answer an auditor, a complaint or the Information Regulator with something better than "we believe so".
What the Act actually asks for
The Act is more demanding about mechanism than many people realise. Section 4(1) sets out eight conditions for lawful processing, each with its own sections: accountability, processing limitation, purpose specification, further processing limitation, information quality, openness, security safeguards and data subject participation.
Three provisions in particular make it clear that a document alone is not the target.
Section 8, the accountability condition, says the responsible party must ensure that the conditions "and all the measures that give effect to such conditions" are complied with, both when the purpose and means of processing are decided and "during the processing itself". That is a duty that runs for as long as the processing runs, not a duty that is discharged at publication.
Section 19(2) requires reasonable measures to identify foreseeable risks, establish safeguards against them, "regularly verify that the safeguards are effectively implemented", and update them as risks change. Verification is in the text. A safeguard nobody checks does not meet the section as written.
Section 17 requires the responsible party to maintain documentation of all processing operations under its responsibility, by reference to the manual requirements in the Promotion of Access to Information Act. That documentation describes processing that is actually happening, so it has to be kept true as systems change.
None of this tells you which technology to use. It tells you that the Act expects processing to be governed by things that operate, and that you can show operating.
Mapping each condition to a control
The most useful single exercise Amanzi did was to take the eight conditions and, for each one, name the system that enforces it and the evidence that system emits. The first draft took two workshops and exposed more than the previous year's policy review had.
The diagram shows the map Amanzi is working towards, simplified. The first draft looked different, and three observations came out of building it.
Some conditions had no control at all. Further processing limitation had no mechanism. New uses of existing data were approved, when they were approved, by whoever happened to be in the meeting. Part 2 of this series is about that gap.
Some controls existed but emitted no evidence. Role-based access in the CRM was configured carefully, but nothing recorded who reviewed it or when. The control was probably working. Amanzi could not prove it.
Several controls belonged to someone else. The telephony provider ran the deletion job for recordings. The collections agency kept its own copies of customer contact details. Section 21(1) requires the responsible party to ensure, through a written contract, that an operator maintains the security measures in section 19, so these controls had to be traced into contracts and confirmations rather than into Amanzi's own systems.
Testing the policy against the systems
With the map in hand, Amanzi took the policy one sentence at a time and asked engineers, not the policy authors, to show the mechanism. Four sentences failed in ways worth describing, because they are typical.
"We keep call recordings for 12 months." The telephony platform's retention setting was "indefinite". It had been changed during a dispute two years earlier, when the legal team needed older recordings, and never changed back. About 40 per cent of stored recordings were older than the promised period.
"We only share your information with service providers under contract." All three operators had contracts. One, the statement-printing house, had a contract that predated the Act and contained no security-measures clause at all.
"You can ask us what information we hold about you." The route described in the policy was an email address. Customers increasingly wrote to Amanzi's WhatsApp channel instead, and those requests were answered informally by call-centre agents, with no log. Part 4 looks at why that is a bigger problem than it looks, now that the April 2025 amendments to the POPIA Regulations name SMS and WhatsApp among the channels for objection and correction requests.
"We use your information to manage your account." The AI call-note summaries were being exported weekly into the warehouse, where the marketing team had started using them to build segments. Nobody had decided that this was a compatible purpose. It had simply become possible.
Not one of these was a policy problem. The policy was fine. Each was a control that did not exist, or a control that existed and had drifted, or a new flow that nobody had mapped against the promise.
The control register
Amanzi replaced its annual policy review with a control register. It is a plain table, kept in the same repository as the architecture records, with one row per promise.
| Field | What goes in it | Amanzi example |
|---|---|---|
| Promise | The sentence from the policy or notice | "Recordings kept for 12 months" |
| Condition and section | Where in the Act it comes from | Purpose specification, s14 |
| Control | The mechanism, specific enough to point at | Telephony retention job, 365 days |
| Owner | A named role, not a team | Contact-centre platform owner |
| System | Where the control runs | Cloud telephony (operator) |
| Evidence | What it produces, and where it is kept | Monthly deletion count, platform export |
| Test | How and how often someone checks it | Quarterly sample of 20 recordings by age |
| Last result | Date and outcome of the last test | Passed, 2026-10-01 |
Two rules keep the register honest. First, a row with no evidence column filled in is reported as a gap, not as compliant. Second, the person who tests the control is not the person who owns it, which is the same separation the Technology Health Check series recommends for findings and corrective actions.
The register also becomes the input to the documentation section 17 requires. Instead of writing a description of processing from memory once a year, Amanzi generates it from rows that engineers maintain as systems change.
Why AI features make this urgent
Every AI feature adds rows to the register, and they are rows people forget. Amanzi's call-note summariser created at least five new kinds of record: the transcript sent to the model, the prompt, the generated summary, the trace log kept for debugging and the vector index the summaries were later embedded into for search. Each is personal information about the caller. Each needs a lawful basis, a retention rule, a place in access-request searches and a security control.
The AI and POPIA series covers how to decide which data an AI service may see in the first place, and Confidentiality before convenience covers what may enter which service. The control register is what happens after that decision: the feature is approved, so now its promises need mechanisms.
A useful habit is to make "register rows added" a required part of any AI feature's definition of done. If a feature creates a new store of personal information and the register did not change, something has been missed.
Signs your policy is ahead of your controls
- The privacy policy was updated more recently than any retention setting in production.
- Nobody can name the system that enforces a sentence in the policy without checking with someone else.
- Operator contracts are stored by procurement and have never been read by the people who run the integration.
- Access requests arrive on channels the policy does not mention.
- An AI feature went live and the policy, not the register, was what changed.
- The answer to "how do we know?" is a person's name rather than a log.
Start this week
- Pick five sentences from your privacy policy and, for each, ask an engineer to show the control and the most recent evidence that it ran. Record what you find without fixing anything yet.
- Build the first eight rows of a control register, one per condition in section 4(1), naming the system and owner for each. Leave the evidence column empty where there is none. The empty cells are your plan.
- List every operator that holds personal information on your behalf and check that each contract contains the security-measures obligation section 21 requires.
Next: Part 2, Lawful basis is a design input, not a legal footnote. All parts are on the series page.
How CloudNala can help
CloudNala runs POPIA controls reviews for technology teams. We take your privacy policy and notices, map each promise to the system and operator that should enforce it, test a sample of those controls against live configuration and logs, and leave you with a working control register and a prioritised list of gaps. We work alongside your information officer and legal advisers, and we do not give legal opinions: our job is to show whether the systems do what the documents say.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a POPIA Controls Review or write to us at consult@cloudnala.co.za