POPIA compliance for marketing agencies handling client social media data

Most SA agency-side conversations about POPIA stop at “our website has a privacy policy.” The harder question is what your operational compliance looks like — specifically, what the Protection of Personal Information Act says about agencies that handle their clients' social media data.

The short answer: when you're running social analytics for a client, you're processing personal information of their users, not just your own. The legal relationship between you and that data is not the same as the relationship between you and your own subscribers. If you don't have that distinction explicitly written down in your client agreements, you're carrying risk you didn't sign up for.

1. Who is the Responsible Party — you, or your client?

POPIA Section 1 defines two key roles:

• Responsible Party: the entity that determines the purpose and means of processing personal information. They carry the legal accountability.
• Operator: a person or entity that processes personal information on behalf of a Responsible Party in terms of a contract or mandate.

For 95% of agency engagements, the client is the Responsible Party (it's their users, their decision to run the marketing, their purpose), and the agency is the Operator. You're processing under their direction, on their behalf.

That distinction matters because Operators have specific obligations under Section 21 of POPIA:

• You may only process personal information with the knowledge or authorisation of the Responsible Party.
• You must treat personal information that comes into your knowledge as confidential.
• You must establish and maintain “reasonable and appropriate” security measures to protect that information.
• You must notify the Responsible Party immediately of any compromise.

If you're not contractually positioned as an Operator with these obligations spelled out, the regulator could read the relationship as joint Responsibility — meaning you're on the hook for the same accountability the client is. Most agencies don't want that.

2. What your client DPA needs to say

A Data Processing Agreement (DPA) — sometimes called a data sharing agreement or operator agreement — is the contractual instrument that locks down the relationship. At a minimum, your client DPA should cover:

2.1 Scope and purpose of processing

What personal information you'll process, why, and on whose behalf. Don't be vague — “social media management” is too broad. Better: “Operator will collect and analyse engagement metrics, post performance data, and registration timestamps from connected social platforms (Facebook, Instagram, LinkedIn) and from the Responsible Party's user database, for the purpose of producing monthly performance reports and ongoing optimisation of the Responsible Party's social-media strategy.”

2.2 Roles confirmed

Explicitly state that the client is the Responsible Party and the agency is the Operator. This sentence sounds redundant but is the keystone clause that turns the next eight sections into Section 21 obligations rather than joint liability.

2.3 Sub-Operators (your tools)

This is the most-skipped clause and the one that bites hardest. If you're running data through a third-party reporting tool — AgencyAnalytics, DashThis, Whatagraph, Kanvro, or anything else — that tool is a sub-Operator under your contract.

Your DPA should:

• List the sub-Operators you currently use (or describe how you'll notify the client when you onboard a new one).
• Confirm each sub-Operator is contractually bound to the same Section 21 obligations you owe the Responsible Party.
• Specify where each sub-Operator hosts data (jurisdiction matters).
• State that the sub-Operator's data deletion process meets POPIA's “within reasonable time” standard.

2.4 Cross-border transfers

If your reporting tool hosts data outside South Africa (most US-built tools do — AgencyAnalytics on US infrastructure, Whatagraph in the EU, DashThis in Canada), POPIA Section 72 kicks in. You can transfer cross-border, but only if:

• The recipient is bound by laws or binding corporate rules providing “adequate” protection (the EU's GDPR generally satisfies this; the US is more nuanced post-Schrems);
• The data subject consented; OR
• Transfer is necessary for the performance of the contract.

Document which legal basis you're relying on for each tool. “The user signed up to a US-built service” is not always sufficient if your client's users never consented to that processor specifically.

2.5 Security measures

POPIA requires “reasonable and appropriate” security. The phrase is intentionally vague, but the regulator's practical bar includes:

• Encryption of personal information at rest and in transit.
• Access controls scoped to least privilege (your account managers shouldn't have admin access by default).
• Audit trails for who accessed what and when.
• Regular review of these controls, not a one-time setup.

2.6 Breach notification

Section 22 of POPIA requires notification to the Information Regulator and to affected data subjects of any compromise. Your DPA should specify:

• You will notify the Responsible Party within X hours (24–72 is common) of becoming aware of a compromise.
• You will provide all reasonable assistance with the regulator notification and data-subject communication.

2.7 Data subject rights

POPIA gives data subjects the right to access, correct, and delete their personal information. As Operator, you must support the Responsible Party in honouring these requests. Specify:

• The mechanism for the Responsible Party to forward subject requests to you.
• Your turnaround SLA (30 days is the regulatory ceiling; aim faster).
• Specifically: the deletion process — how, where, and what proof of deletion you'll provide.

2.8 Termination and return / deletion of data

On termination of the agency engagement, what happens to the client's data? POPIA expects deletion or return at the Responsible Party's direction, within a reasonable period. Specify a hard deadline (90 days is typical) and what evidence of deletion you'll provide.

3. Where the tool-side risk lives

Most agencies focus on their own POPIA posture and miss that the bigger exposure is often in the tools they use. A few concrete vectors:

3.1 OAuth tokens stored in plaintext

When your reporting tool connects to your client's Facebook Page, the tool stores an access token. If that token is stored unencrypted, anyone with database access (the tool's engineers, the tool's breached attacker) can act as your client's Page admin. This is a Section 22 incident waiting to happen.

What to ask your tool vendor: “Are tokens encrypted at rest? With what algorithm? Where are the encryption keys stored?” Acceptable answers include AES-256 with keys in a managed key-management service. Unacceptable: “our database is encrypted” (that's disk encryption, not application-level token encryption — the difference matters when an engineer queries the database directly).

3.2 No deletion webhook integration

Meta requires every connected app to honour data deletion requests via a deletion-callback URL. Tools that haven't implemented this aren't passing data deletion through to their own systems — meaning your client's former users may still have data in the reporting tool weeks after they deleted their Facebook accounts. That's a Section 22 problem squarely on the agency.

What to ask your tool vendor: “Do you implement Meta's data deletion callback? What's the SLA?”

3.3 Cross-jurisdictional access

Even if data is hosted in a POPIA-compatible jurisdiction, who can access it from where matters. A US-based engineering team querying an EU-hosted database is a cross-border data flow. Your DPA should require the tool vendor to disclose where their team accesses data from.

4. The practical checklist

If you do nothing else after reading this:

• For every active client, confirm you have a signed DPA that names you as Operator and them as Responsible Party.
• List every tool that touches client personal data. For each, document jurisdiction, security posture, deletion process, and your contractual relationship with the vendor.
• Update your privacy policy to disclose the sub-Operators you use.
• Set a calendar reminder to revisit this annually — POPIA enforcement is evolving.
• Train your team on Section 22 (you have hours, not days, to escalate a suspected breach internally).

5. How Kanvro removes tool-side risk

Plug for context: Kanvro is built and hosted in South Africa, which removes the cross-border-transfer question entirely. Specifics:

• Data residency: Google Cloud (us-central1) for compute, with an upgrade path to africa-south1 in 2026 for clients on Command tier who require strict in-jurisdiction processing.
• Token encryption: AES-256 at rest with keys managed by Google Cloud Secret Manager. Tokens are never visible to client-side code; only Cloud Functions with admin-SDK access read them.
• Deletion webhooks: Meta's data-deletion callback (metaDataDeletion) and TikTok's (tiktokDataDeletion) are wired and process within 30 days as POPIA + the platforms require. Status endpoint available so the agency can confirm deletion to the data subject.
• Five-tier RBAC: Super Admin, Kanvro Admin, Agency Admin, Agency Member, Client User. Audit-trailed via Cloud Function logs with 90-day retention.
• SA support hours: SAST timezone for incident response.

None of this is a magic bullet. POPIA compliance is a programme, not a checkbox. But the tool-side risk surface — encryption, deletion, residency — is one less thing to argue about in your client DPA conversations.

If you want a copy of the DPA template we use with founding-partner agencies (a starting point — your lawyer should still review it), email hello@kanvro.com.