POPIA Compliance for Web Developers and Agencies

You are an operator, and that is a legal position

If you build or maintain websites for South African clients, POPIA already applies to you. The client is the responsible party, deciding why and how personal information is processed. You are the operator, processing it on their behalf without being under their direct authority.

That is not a metaphor. It is a defined role with obligations attached, and most agencies are carrying them without knowing.

Section 21 requires a written contract, and you probably do not have one

This is the single most important thing on this page. Section 21 requires a written contract between responsible party and operator, obliging the operator to establish and maintain the security measures in section 19.

A proposal, a quote and an invoice do not satisfy it. Nor does a hosting agreement that only covers uptime. What you need in your standard terms:

• That you process personal information only with the client's knowledge or authorisation, and not for your own purposes
• That you treat it as confidential and do not disclose it, unless required by law or in the proper performance of your duties
• That you maintain the section 19 safeguards: appropriate technical and organisational measures, identifying reasonably foreseeable risks, and verifying that they work
• That you notify the client immediately where there are reasonable grounds to believe personal information has been accessed by an unauthorised person. Section 21(2) makes this explicit, and it matters because the client's own section 22 breach clock depends on hearing from you
• What happens to the data at the end of the engagement, and whether you may use sub-operators

Two commercial reasons to do this beyond compliance. It is increasingly asked for in procurement, so having it ready wins work. And it defines the boundary of your liability rather than leaving it to be argued after an incident. See operator agreements under section 21.

The consent checkbox advice you should stop following

A common instruction in developer guides, including an earlier version of this article, is to put a mandatory "I agree to the Privacy Policy" tick box on every form. Do not build this.

POPIA requires notification under section 18, not consent, and a contact form enquiry rests on section 11(1)(b) or (f), not on consent. Forcing agreement to a privacy policy confuses a notice with a lawful ground, and it makes the client's position weaker rather than stronger, because it implies consent was the ground and consent can be withdrawn.

What to build instead:

• A visible link to the privacy policy at the point of collection. That discharges section 18.
• A separate, unticked checkbox for marketing, because that genuinely does need consent under section 69.
• Storage of what the user was shown, not just that they ticked. Section 11(2)(a) puts the burden of proving consent on your client.

Cookie banners that actually work

Installing analytics or an advertising pixel that fires on page load, with a banner that appears afterwards, records a decision the site has already ignored. A compliant implementation:

• Blocks non-essential scripts until a choice is made, rather than asking and loading anyway
• Makes refusing as easy as accepting, in one click at the same level
• Lets the choice be changed later, through a link that remains reachable
• Treats strictly necessary cookies separately, since those do not need consent

Google Consent Mode and similar tools help, but only if configured to deny by default. See is your cookie banner POPIA compliant.

Build decisions that are compliance decisions

• HTTPS everywhere. Section 19 requires appropriate technical measures, and transport encryption is the floor, not the ceiling.
• Collect less. Section 10 is the minimality condition. A newsletter form asking for a physical address is a defect you built.
• Where the data lives. Hosting a South African client on overseas infrastructure is a cross-border transfer under section 72. It is usually fine, but the client's privacy notice has to say so, and you are the one who knows.
• Access after handover. If you keep admin credentials or database access after launch, you are still an operator. Decide deliberately whether to keep it, and reflect it in the contract.
• Form submissions to email. A contact form that emails an unencrypted spreadsheet to a shared mailbox is a design you chose.

The legal pages, and the copy-paste problem

Every client site needs a privacy policy, and most need terms. Agencies commonly copy one client's policy to the next, which produces a document describing a business the client does not run. That fails section 18 for the client, because the notification is inaccurate, and it is your fingerprints on it.

If the client sells online, their terms also need the ECT Act section 43 supplier disclosures, and their checkout needs the section 43(2) review, correct and withdraw step before payment. That is a build requirement, not a legal one they can bolt on afterwards. See website terms and conditions in South Africa.

What to hand over at launch

• A signed operator agreement
• Privacy policy, terms, cookie policy, and a PAIA manual if the client has none
• A note of every third party the site sends data to, since the client has to disclose them
• Where the site and its backups are hosted, and in which country
• Who retains access, and how to revoke it
• Confirmation that the cookie banner blocks before consent

This list is worth charging for. It is also the difference between an agency that hands over a website and one that hands over a website its client can defend.

POPIA Ready generates client-specific documents from answers about their actual business, so you are not copying one client's policy onto the next. Free to preview. The free checklist works well as a handover document.

General guidance on South African law as at August 2026, not legal advice. Where liability sits between an agency and its client depends on the contract and the facts, and a specific arrangement deserves a professional opinion.