Appointing a supplier does not appoint away your data breach

What the Information Regulator actually said

The Information Regulator announced its briefing on 27 August 2026 and delivered it four days later, on 31 August 2026. The content was not a single case decision. It was a status update: active investigations, ongoing enforcement activity, and a continued institutional focus on security compromises reported to the Regulator by responsible parties, alongside the Regulator’s broader work on organisational compliance with the Protection of Personal Information Act and the Promotion of Access to Information Act.

That framing matters. This was not one company being named over one incident. It was the regulator signalling where its attention sits on an ongoing basis, which is exactly the kind of signal that should change how businesses negotiate their next supplier contract, not just how they react to their last one.

Why appointing a supplier does not transfer the risk

POPIA’s structure puts the obligation on the responsible party, the business that determines the purpose and means of processing, not on the operator carrying it out. When a business puts customer or employee data into a cloud platform, a SaaS tool, a hosting environment, or an outsourced IT function, it has changed who is doing the processing. It has not changed who answers for it.

That distinction gets lost in ordinary commercial thinking, where appointing a specialist supplier is usually treated as a way of transferring a problem you don’t want to carry yourself. Data protection does not work that way. The supplier can be negligent, breached, or simply out of contractual scope for the incident that occurs, and the responsible party is still the one the Information Regulator will ask to explain what happened and why.

What a processing arrangement has to define

A commercial lesson follows directly from the accountability point: the processing arrangement between a business and its cloud, SaaS, hosting or outsourced technology provider needs to do real work, not just exist. Six things it should define, specifically and in writing, rather than by inference from a general services agreement.

• Security standards the operator must maintain, described in terms that can be checked, not just “appropriate” or “industry standard” language that means nothing until something has already gone wrong.
• Breach notification timing, a fixed number of hours or days from when the operator becomes aware of a compromise, not “without undue delay” left open to argument at the worst possible moment.
• Cooperation duties during an investigation, so the supplier is contractually obliged to provide facts, logs and access rather than simply agreeing to “assist as reasonably required”.
• Audit evidence, a right to see assurance reports, certifications or actual audit findings, not just a warranty that controls exist somewhere behind the supplier’s own walls.
• Sub-processor controls, so your data does not move to a fourth or fifth party you have never heard of without your knowledge or approval.
• Responsibility for remediation, stated clearly enough that nobody is negotiating who pays for the clean-up while the clean-up is still happening.

What to check in your existing DPA or supplier contract now

Most businesses already have a data processing agreement or a supplier contract with security clauses in it. The question the Information Regulator’s continued enforcement focus raises is not whether the clause exists, but whether it was actually built around the processing it governs, or bolted on from a template.

Worth checking specifically: whether security obligations are described with any specificity at all, whether breach notification has a real deadline attached to it, whether sub-processor appointment requires your prior consent rather than notice after the fact, whether you have an enforceable right to audit evidence rather than a bare promise, and whether termination rights exist for a material security failure rather than only for non-payment or ordinary breach.

Indemnities and liability caps need to match the data, not the deal size

Indemnities and liability caps in a supplier contract are usually negotiated the way every other commercial term is negotiated: against deal value, negotiating leverage, and what each side’s standard paper says. That is the wrong benchmark for personal information processing.

The right benchmark is the actual exposure the processing creates. A supplier handling a small volume of low-sensitivity marketing data creates a different risk profile to one handling payroll records, health information, or financial account data for thousands of data subjects. A liability cap set at twelve months’ fees might be entirely reasonable for the first and hopelessly inadequate for the second. Test the indemnity and the cap against what a real compromise of that specific data would actually cost you, in notification, remediation and regulatory exposure, rather than accepting whatever figure the supplier’s standard terms happen to offer.

What happens after a security compromise, contractually

When an operator suffers a security compromise, POPIA’s assessment and notification obligations still sit with the responsible party. The business that appointed the supplier has to work out whether the compromise triggers a notification duty, what to tell affected data subjects, and what to tell the Information Regulator, often against a tight timeline.

If the contract does not oblige the supplier to notify quickly, share what it knows, and support the remediation effort, the responsible party is doing all of that assessment work with whatever information the supplier chooses, or manages, to provide. That is the practical cost of a processing arrangement negotiated as boilerplate: it shows up not at signature, but in the first hours after an incident, when there is no time left to negotiate it properly.