What is a Data Protection Addendum (DPA)?
Is a Data Protection Addendum legally required in South Africa?
“A responsible party must, in terms of a written contract between the responsible party and the operator, ensure that the operator which processes personal information for the responsible party establishes and maintains the security measures referred to in section 19.”
“The operator must notify the responsible party immediately where there are reasonable grounds to believe that the personal information of a data subject has been accessed or acquired by any unauthorised person.”
“An operator or anyone processing personal information on behalf of a responsible party must process such information only with the knowledge or authorisation of the responsible party and treat the personal information that comes to their knowledge as confidential.”
“A responsible party must secure the integrity and confidentiality of personal information in its possession or under its control by taking appropriate, reasonable technical and organisational measures to prevent loss of, damage to, or unauthorised destruction of personal information and unlawful access to or processing of personal information.”
When you need a Data Protection Addendum
- Whenever you appoint a supplier that will process personal information on your behalf — a cloud or SaaS provider, payroll bureau, hosting company, call centre, mailing house, debt collector, marketing agency, or IT support firm — section 21 requires a written DPA before processing starts.
- When you are the supplier (the operator) and your customers ask you to sign their DPA, or you offer your own — so that your obligations match what you can actually deliver and your sub-processors are properly flowed down.
- When personal information will be hosted or processed outside South Africa — for example on a cloud platform with offshore data centres — so the cross-border transfer conditions in section 72 are addressed in the contract.
- When you engage a sub-processor (a sub-operator) under an existing arrangement and need the customer’s authorisation and a back-to-back DPA passing the same duties down the chain.
- When a services, outsourcing, or technology agreement is silent on data protection, or relies on a generic GDPR clause, and needs a POPIA-correct addendum that mirrors rather than contradicts the main contract.
What a Data Protection Addendum should contain
Roles: responsible party and operator
State plainly who is the responsible party and who is the operator for the personal information in question, using POPIA’s section 1 terms rather than “controller/processor”. This matters because the operator’s duties under sections 20 and 21 only attach where the supplier is genuinely processing for the customer; if the supplier sets its own purposes it is a responsible party and a different agreement is needed.
Scope and purpose of processing
Define the categories of data subjects and personal information, the nature and purpose of the processing, and the duration. This anchors the section 20 rule that the operator may process only with the responsible party’s knowledge or authorisation, and supports purpose limitation — the operator must not use the data for its own ends.
Processing on documented instruction
Bind the operator to process personal information only on the responsible party’s instructions and within the agreed purpose, and to flag any instruction it believes is unlawful. This is the contractual expression of section 20 and keeps control of the data with the responsible party who carries the POPIA accountability.
Security safeguards (section 19)
Require the operator to establish and maintain appropriate, reasonable technical and organisational measures to secure the personal information — the substantive standard section 19 sets and that section 21(1) compels you to impose by written contract. Spell out, or schedule, the concrete controls (access control, encryption, backups, logging) so “appropriate and reasonable” is measurable rather than aspirational.
Confidentiality undertaking
Oblige the operator and its personnel to treat the personal information as confidential and not to disclose it unless required by law or in the proper course of performing the services, reflecting section 20’s confidentiality duty. Tie this to the personnel actually handling the data so the obligation reaches the people, not just the company.
Security-compromise notification (section 21(2))
Require the operator to notify the responsible party immediately on reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person, with enough detail for the responsible party to meet its own section 22 duty to notify the Information Regulator and affected data subjects. Set timelines and a contact route so “immediately” is operational.
Sub-operators (sub-processors) and flow-down
Control whether and how the operator may appoint sub-operators — typically requiring the responsible party’s prior authorisation and a back-to-back written contract imposing the same data-protection obligations down the chain. Without this, the security and confidentiality duties stop at the first supplier while the data keeps moving.
Cross-border transfers (section 72)
Address any transfer of personal information outside South Africa — for offshore cloud hosting in particular — against the section 72 conditions: an adequate-protection regime, data-subject consent, necessity for the contract, or the responsible party’s authorised binding arrangement. Identify the hosting locations so the responsible party can satisfy itself the transfer is lawful.
Return or deletion on termination
Require the operator, at the end of the services or on request, to return or securely delete the personal information and existing copies and to certify it has done so, subject only to retention the law requires. This closes out the residual risk once the relationship ends and supports POPIA’s retention-limitation principle.
Audit, assistance and consistency with the main agreement
Give the responsible party reasonable rights to verify compliance and require the operator to assist with data-subject requests and regulator queries — and state expressly that the DPA prevails on data-protection matters but otherwise sits consistently with the main agreement, so the addendum mirrors rather than contradicts the contract it is attached to.
POPIA Data Protection Addendum vs GDPR DPA vs an NDA
| Feature | POPIA DPA (operator addendum) | EU GDPR DPA (Art 28) | NDA / confidentiality |
|---|---|---|---|
| Governing law | POPIA (Act 4 of 2013) | EU General Data Protection Regulation | Common law of contract |
| Parties named | Responsible party and operator | Controller and processor | Discloser and recipient |
| Mandatory? | Yes — written contract required by s 21 | Yes — written contract required by Art 28 | No — used by choice |
| Core duties | s 19 security, s 20 confidentiality, s 21(2) breach notice, s 72 transfers | Art 32 security, Art 28 sub-processor/breach terms, Chapter V transfers | Keep defined information secret |
| Sub-suppliers | Sub-operators authorised + flow-down | Sub-processors authorised + flow-down | Permitted disclosures to advisers |
| Typical use | Cloud, SaaS, payroll, outsourcing in SA | EU/EEA personal-data processing | Pitches, due diligence, talks |
Common South African pitfalls
- Treating the DPA as optional: section 21 makes the written contract compulsory, so beginning to share personal information with a supplier before a DPA is signed already puts the responsible party in breach of POPIA — the addendum must be in place before processing starts, not bolted on after an incident.
- Bolting on a GDPR template unchanged: an imported EU DPA refers to “controller/processor” and GDPR Articles that do not exist in South African law. Left unedited it can name the wrong duties, miss POPIA’s section 72 transfer test, and contradict the main SA agreement — the controls translate, but the statute and terminology must be re-pointed at POPIA.
- Confusing operator with responsible party: if the supplier in truth decides its own purposes for the data, it is a responsible party, not an operator, and a DPA is the wrong instrument. Mislabelling the roles can leave neither party carrying the POPIA accountability it actually bears.
- Vague or missing security schedule: section 19 demands “appropriate, reasonable technical and organisational measures”, but a clause that just repeats that phrase is unmeasurable. Without a concrete schedule of controls, the responsible party cannot show it imposed real security as section 21(1) requires.
- Uncontrolled sub-operators: allowing the operator to appoint sub-processors without authorisation and back-to-back flow-down lets personal information move down a chain where the security and breach-notification duties no longer apply — a common and serious gap in cloud arrangements.
- Ignoring offshore hosting: hosting personal information on overseas data centres is a cross-border transfer governed by section 72. A DPA that is silent on where the data physically sits leaves the responsible party unable to show the transfer met one of the lawful bases, even though the cloud contract looks complete.
Frequently asked questions
Is a Data Protection Addendum legally required under POPIA?
Yes. Section 21(1) of POPIA requires a responsible party to ensure, in terms of a written contract with the operator, that the operator maintains the security measures POPIA demands. So whenever a supplier processes personal information on your behalf, a written DPA is compulsory — not optional — and must be in place before processing begins.
What is the difference between a responsible party and an operator?
These are POPIA’s section 1 terms. The responsible party is the customer who determines the purpose and means of processing personal information — the equivalent of the GDPR “controller”. The operator is the supplier who processes that information for the responsible party without coming under its direct authority — the equivalent of the GDPR “processor”. The DPA records which party is which.
How does a POPIA DPA differ from a GDPR DPA?
They cover similar ground — security, confidentiality, sub-processor control, breach notification, and restrictions on international transfers — but use different terminology and law. A POPIA DPA speaks of “responsible party” and “operator” and cites POPIA sections 19 to 22 and 72, whereas a GDPR DPA speaks of “controller” and “processor” and cites Article 28. An imported GDPR template must be re-pointed at POPIA.
Who must report a data breach under a POPIA DPA?
Both, in sequence. Under section 21(2) the operator must notify the responsible party immediately where it has reasonable grounds to believe personal information was accessed or acquired by an unauthorised person. The responsible party then carries the section 22 duty to notify the Information Regulator and affected data subjects. A good DPA sets timelines so the operator’s notice gives the responsible party what it needs.
Can my supplier use sub-processors under a DPA?
Only if the DPA allows it. POPIA’s framework requires the operator to process only with the responsible party’s knowledge or authorisation, so a well-drafted DPA controls sub-operators — typically requiring prior authorisation and a back-to-back written contract that flows the same security, confidentiality, and breach-notification duties down the chain.
Does a DPA cover hosting our data overseas?
It should. Hosting personal information on offshore data centres is a cross-border transfer governed by section 72 of POPIA, which permits transfer only on grounds such as adequate protection in the destination, data-subject consent, necessity for the contract, or an authorised binding arrangement. A DPA used with a cloud supplier should identify the hosting locations and address the section 72 basis.
What security must the operator provide under section 19?
Section 19 requires “appropriate, reasonable technical and organisational measures” to secure personal information against loss, damage, unauthorised destruction, and unlawful access or processing. Section 21(1) compels the responsible party to impose that standard on the operator by written contract. Best practice is to schedule concrete controls — access control, encryption, backups, logging — so the standard is measurable.
Should the DPA override the main services agreement?
It should sit consistently with it, not contradict it. A DPA is an addendum to a main services, cloud, or outsourcing agreement, and is usually drafted to prevail on data-protection matters while leaving the rest of the contract intact. If the DPA and the main agreement conflict on liability, term, or instructions, the inconsistency itself becomes a compliance and dispute risk.
Sources & authority
- Protection of Personal Information Act 4 of 2013 (POPIA), s 21 — operator written contract & breach notice
- Protection of Personal Information Act 4 of 2013 (POPIA), s 20 — processing limitation & confidentiality
- Protection of Personal Information Act 4 of 2013 (POPIA), s 19 — security safeguards
- Protection of Personal Information Act 4 of 2013 (POPIA), s 72 — transfers outside the Republic
This guide is general information, not legal advice. It reflects the law as at June 2026.