At most organisations the question "are we allowed to use this data for that?" arrives late. A team builds a pipeline, a dashboard or an AI feature, it works, and then someone asks whether it is permitted. The question goes to legal by email. The answer comes back weeks later as a paragraph of careful prose. By then the data has been flowing for a month, two other teams have started using the output, and the paragraph is filed somewhere nobody in engineering will ever read it.
That sequence treats lawful basis as a legal footnote to an engineering decision. It is the wrong way round. The purpose for which information was collected, and the justification for processing it, decide what may be built on top of it. They are design inputs, in the same category as data types, volumes and latency.
CloudNala's view is that purpose and lawful basis should be recorded as attributes of the data, set at collection, carried through every pipeline and checked by machines whenever a new use is proposed. Legal judgement is still needed for hard cases. It should be applied at a gate the system cannot bypass, not in an email the system never sees.
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 2 of POPIA in Production. Part 1 introduced the control register and found that Amanzi had no mechanism at all for the further processing condition. This part builds one.
Amanzi Credit is fictional, and its systems and figures are illustrative. It is a Gqeberha store-card and personal-loan lender with about 180,000 customers. Its AI assistant summarises every call-centre conversation into a CRM note. Six months after launch, the marketing team noticed the summaries in the data warehouse and started using them to build customer segments.
What sections 11, 13 and 15 say
Three parts of the Act frame the problem.
Section 11(1) lists the only justifications for processing personal information. In summary: the data subject (or a competent person for a child) consents; processing is necessary to conclude or perform a contract the data subject is party to; it complies with an obligation imposed by law; it protects a legitimate interest of the data subject; it is necessary for a public body's proper performance of a public law duty; or it is necessary for the legitimate interests of the responsible party or a third party to whom the information is supplied. Section 11(2)(a) places the burden of proving consent on the responsible party, and section 11(3) and (4) give the data subject a right to object in defined circumstances, after which the information may no longer be processed.
Section 13(1) requires personal information to be collected "for a specific, explicitly defined and lawful purpose related to a function or activity of the responsible party", and section 13(2) requires steps to make the data subject aware of that purpose.
Section 15(1) requires further processing to be "in accordance or compatible with the purpose for which it was collected". Section 15(2) lists the factors to weigh when deciding compatibility, and section 15(3) lists situations in which further processing is not incompatible, consent among them.
Read together, these sections mean every record of personal information arrives with a purpose and a justification attached, whether or not your systems record them. The only question is whether the attachment is visible to the people and pipelines that reuse the data.
Purpose is an attribute, not a paragraph
Amanzi's fix began with its data model. Every store that holds personal information now carries a small set of fields at record or dataset level:
| Attribute | Meaning | Example for a call-note summary |
|---|---|---|
| Purpose | The specific purpose stated at collection | Servicing the customer's account |
| Lawful basis | The section 11(1) justification relied on | Performance of the credit agreement |
| Collected via | Channel and notice version shown | Call centre, notice v4.2 |
| Retention rule | The rule that governs deletion (Part 3) | R-07: closure plus 3 years |
| Decision role | Whether outputs feed decisions about the person | Informational only |
| Objection status | Whether the person has objected under s11(3) | None |
The fields are not legal analysis. They record the conclusions of legal analysis in a form a pipeline can read. When a dataset is derived from another, it inherits the most restrictive values, and any change to purpose or basis has to come through the gate described below.
Two things follow immediately. Collections staff can read the summary, because Amanzi's legal team has recorded that chasing arrears on the account falls within the servicing purpose. A marketing job that tries to read the same summary declares a different purpose, and the platform refuses it until someone has assessed whether that purpose is compatible.
Choosing the basis at design time
For each new flow, Amanzi now chooses the basis before the build starts and writes it into the feature's specification. A few examples show why the choice changes the design.
Loan applications rely on the contract basis in section 11(1)(b), which covers processing "necessary to carry out actions for the conclusion or performance of a contract". Amanzi reads that as covering the data needed to assess and conclude the agreement, and not as stretching to unrelated uses just because the data is already there.
Affordability assessment relies on an obligation imposed by law, section 11(1)(c), where credit legislation requires the assessment. Amanzi's legal team records the specific statutory provision in the register, so engineers do not have to infer it.
Call recording for quality assurance relies on Amanzi's legitimate interests, section 11(1)(f). Because objection under section 11(3)(a) is available for processing on that basis, the call flow needs a way to record an objection and a way to honour it, such as stopping recording for that customer.
Consent is used sparingly. It is not the safe default people assume. Section 11(2)(a) puts the burden of proving it on Amanzi, and the Act allows it to be withdrawn, so consent-based processing needs a consent record, a withdrawal path and downstream deletion or suppression. Where another basis genuinely applies, Amanzi uses it and says so in the notice.
The further-processing gate
The marketing team's request was the case that made the gate necessary. They wanted to use phrases from call summaries ("asked about increasing limit", "mentioned school fees") to target offers.
Amanzi's gate is a short form attached to the feature's specification. The feature owner answers each of the section 15(2) factors, the information officer reviews the answers, and the outcome is recorded as a register row. For the marketing request, the answers were uncomfortable.
Relationship between the purposes. Servicing an existing account and selling new credit are related only loosely.
Nature of the information. Free-text call summaries regularly contain things customers said in distress: retrenchment, illness, a death in the family. Some of that is special personal information under section 26, which starts from a prohibition with exceptions rather than a permission.
Consequences for the data subject. Targeting extra credit at people who recently described financial hardship on a support call has obvious potential for harm.
How it was collected. In a service call, where the customer was asking for help, not shopping.
Contractual rights and obligations. The credit agreement said nothing about marketing use of call content.
The outcome was "incompatible as designed". The redesign used product holdings and preferences customers had explicitly set in the app, not call content, and routed any direct marketing through the separate rules for electronic direct marketing, which the Engineer the Go-to-Market System series covers. Aggregate, de-identified call themes ("limit increase questions rose this quarter") were allowed for product planning, which sits closer to the statistical purposes section 15(3)(e) contemplates, provided nothing is published in identifiable form.
When the output feeds a decision about a person
The "decision role" attribute exists because of section 71. It provides that a data subject may not be subject to a decision with legal consequences, or that affects them to a substantial degree, based solely on automated processing intended to provide a profile of them, which expressly includes creditworthiness. Section 71(2) sets out exceptions, and section 71(3) requires that, where the contract exception relies on appropriate measures, the person has an opportunity to make representations and receives sufficient information about the underlying logic of the processing.
For a lender, that matters the moment an AI summary or a model score starts influencing whether someone gets credit, a limit change or a collections action. Amanzi's rule is simple: any dataset with "decision role: informs decisions" cannot be consumed by an automated decision path without a documented human step or a documented section 71 assessment. The AI Before the Rulebook series explains why AI assistance should not inherit decision authority; this attribute is how a platform enforces that view.
Making it enforceable in pipelines
Attributes only help if something reads them. Amanzi made three changes to its data platform.
Jobs declare a purpose. Every scheduled pipeline, notebook and AI feature that reads personal information declares the purpose it serves, in configuration that is code-reviewed.
Reads are checked. The platform compares the declared purpose with the allowed purposes on the source dataset. A mismatch fails the job and points to the gate. This is a deterministic check, not a model's opinion.
Objections propagate. When a customer objects under section 11(3), the objection status changes at the source and every derived dataset that relies on the affected basis excludes that customer on its next run.
The checks are deliberately coarse. Amanzi has about a dozen purposes, not hundreds. Finer granularity looked attractive and turned out to be unmaintainable.
The trade-off
This is not free. Tagging legacy data is slow, and some old datasets have no reliable record of how they were collected; Amanzi labelled those "purpose unknown" and blocked new uses of them until someone did the work. Purpose checks occasionally block legitimate jobs, and the gate adds days to features that reuse data. A tag can also give a false sense of precision if nobody reviews whether it is still true.
The alternative cost is larger and arrives later: features built on data they should never have touched, discovered during a complaint, an access request or an incident, when unwinding them means rebuilding the feature and explaining the history.
Start this week
- Choose your three highest-volume stores of personal information and record purpose, lawful basis and retention rule for each, even if only as a table in the control register.
- Add a lawful-basis line to your feature specification template, so the basis is chosen before the build starts.
- List every place AI-generated text about customers is stored and check what other jobs read it. Any reader with a different purpose goes through a compatibility assessment.
Next: Part 3, Retention is a deletion pipeline, not a schedule. All parts are on the series page.
How CloudNala can help
CloudNala helps data and platform teams turn lawful-basis decisions into enforceable design. We map purposes and justifications across your highest-risk stores, design the attributes and pipeline checks that carry them, and set up a further-processing gate that your information officer can run without becoming a bottleneck. Legal conclusions remain with your legal advisers; we make sure the systems can see and respect them.
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