Is your website POPIA-compliant? A practical checklist

Most POPIA compliance conversations happen inside the business — policies, registers, staff training. Your website is the one part of your POPIA posture that’s public. A customer, a journalist, a competitor, a procurement officer running due diligence, or an Information Regulator investigator can check it in under a minute, with no cooperation from you required. It’s also where the cheapest, most visible, most easily fixed gaps tend to sit.

This is a practical, run-it-yourself checklist. It won’t make you fully POPIA-compliant on its own — POPIA compliance is an organisational programme, not a website feature — but it will tell you, in about fifteen minutes, where your most visible exposure is.

The Checklist

1. Privacy policy — present and actually reachable.Not just published somewhere, but linked from your site’s footer or navigation on every page, not buried three clicks deep. It should name your Information Officer, state what personal information you collect and why, and explain how someone exercises their rights.
2. Cookie and tracker consent — functional, not decorative.A banner that displays text but loads analytics and ad pixels before the visitor clicks anything isn’t consent — it’s theatre. Check what actually fires on first page load before any button is clicked. If it’s more than strictly necessary cookies, you have a gap.
3. A real data subject rights channel.Section 23 gives people the right to request access to their information; section 24 gives them the right to request correction or deletion. Does your site have an actual email address, form, or process for this — one that someone monitors — or does the privacy policy just gesture at the right without a working mechanism behind it?
4. Information Officer designation.Named, registered with the Information Regulator, and contactable. “Our legal team” is not a designation. A person’s name and a working email address is.
5. Lawful basis for every form on the site.Contact forms, newsletter signups, checkout flows, quote requests — each one collects personal information, and each one needs a lawful basis (usually consent, or necessity for a contract). If a form collects more than it needs for its stated purpose, that’s a Condition 3 (purpose specification) problem waiting to surface.
6. Third-party tracker audit.Run your site through a browser’s network tab or a scanning tool and see what’s actually calling out — analytics, ad networks, embedded video players, chat widgets, font services. Every one of them is a potential data recipient. Is each one disclosed, and does each one need to be there?
7. Mail-server and domain hygiene — SPF, DKIM, DMARC.Not obviously a “privacy” item, but a misconfigured mail setup is a spoofing and phishing vector that puts customer and staff personal information at direct risk, and it’s a five-minute DNS check. This is one of the checks our own POPIA scan runs automatically every month, because it’s cheap to check and expensive to ignore.
8. TLS and transport security.HTTPS enforced site-wide, HSTS header present, no mixed-content warnings. Table stakes, and still missed more often than you’d expect on older sites that were never revisited after launch.
9. Baseline security response headers.Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy. These won’t stop a determined attacker on their own, but their absence is exactly the kind of “didn't check” signal that undermines a section 19 defence — see our full breakdown of what section 19 actually requires for why this matters beyond the headers themselves.
10. A retention policy for form submissions.If someone submitted an enquiry two years ago and never became a customer, do you still have that data? Do you know how long you’re allowed to keep it? Section 14 requires you not to retain personal information longer than the purpose it was collected for requires — indefinite retention with no policy is a straightforward gap.
11. Cross-border hosting disclosure.If your website, email, or analytics run through US or EU-based infrastructure (most do), section 72 requires a lawful basis for that cross-border transfer, and your privacy policy should say where data actually goes, not just that it’s “securely stored.”
12. Breach-response readiness.Not something a visitor can check by looking at your site, but worth asking honestly: if you discovered a compromise tomorrow, does anyone in your business know that section 22 requires notifying the Information Regulator and affected data subjects “as soon as reasonably possible” — and who would actually make that call?

What “Good” Actually Looks Like

The gap between a website that passes this checklist and one that doesn’t is rarely a technology gap. It’s usually that items 1–5 were done once, at launch, by whoever built the site, and never revisited — while items 6–9 were never explicitly checked at all because nobody thought of the website as a POPIA surface in the first place. Regulators and procurement due-diligence teams tend to look at exactly these items first, precisely because they’re checkable without cooperation.

How Often Should You Check This?

Most businesses check this once, around the time they first hear about POPIA, and then not again until something goes wrong or a customer’s procurement team asks. That’s a twelve-month gap in which a new tracking pixel gets added by a marketing team, a certificate quietly expires, or a form gets rebuilt without anyone re-checking its lawful basis. The items on this list — especially the technical ones (TLS, headers, mail-server configuration, tracker inventory) — are the kind that drift silently. A monthly automated check catches drift the month it happens rather than the year someone finally looks again, which is the specific gap Komply’s POPIA module is built to close.

Two Ways to Close the Gaps You Find

Running this checklist tells you where you stand. Closing what it finds usually means one of two things:

• Get an exploit-confirmed read on the technical side.This checklist catches the visible, surface-level gaps. It won’t tell you whether your login form is vulnerable to injection or whether an admin panel is exposed to the internet. For that level of assurance — the kind a bank or insurer’s security questionnaire actually wants to see — Deep Scan runs a confirmed scan against your live site and hands you a proof-of-concept for every finding, not a generic vulnerability list.
• Get it fixed, not just flagged.If the gaps are more than a quick internal fix — a privacy policy that needs rewriting, a cookie mechanism that needs rebuilding, forms that need restructuring — Auto Alpha Advisory will build and fix it for you rather than leave you with a findings list and no capacity to act on it.