POPIA Records of Processing Activities: A Practical Checklist

Section 17 of the Protection of Personal Information Act requires a responsible party to maintain documentation of all the processing operations under its responsibility, with reference to the information that section 14 and section 51 of the Promotion of Access to Information Act require in the PAIA manual. In practice that documentation is a record of processing activities, usually called a ROPA. For a financial services provider or a credit provider, which processes identity numbers, financial information and sometimes health information for every client, the ROPA is the backbone of the POPIA compliance framework the Information Officer must have under Regulation 4.

What a ROPA is for

Three things. It tells the Information Officer what personal information the business holds and why, which is the starting point for every other POPIA duty. It supports risk decisions: which processing needs a security safeguard review, which involves a third-party operator who needs a written contract, which transfers information outside South Africa. And it is the record an inspector or a data subject asks for first.

The checklist

For each processing activity, record:

1. The activity in plain words: "client onboarding and FICA verification", "credit application and affordability assessment", "claims administration", "payroll".
2. The purpose of the processing and the lawful basis under section 11 (consent, contract, legal obligation, legitimate interest).
3. The categories of data subjects: clients, prospective clients, representatives, employees, beneficiaries, suppliers.
4. The categories of personal information, flagging special personal information (health, biometrics, criminal history) and information of children, which carry stricter conditions.
5. The source of the information: the data subject, a credit bureau, the FSCA register, an insurer.
6. The recipients, inside and outside the business, including operators (software providers, outsourced administrators, debt collectors) and the contracts in place with each.
7. Transfers outside South Africa, with the section 72 ground relied on (adequate law, binding corporate rules, consent, contract).
8. The retention period and the reason for it (the FIC Act's five years, the FAIS record-keeping requirement, the NCA's prescribed periods, tax law).
9. The security safeguards that apply: access control, encryption, backups, the operator's assurances.
10. The owner inside the business who is accountable for the activity.

Building it without a project team

A small FSP can build a complete ROPA in a working day with the right method:

• Start from the systems, not the law. List every place personal information lives: the CRM, the FICA folder, the email archive, the payroll system, the shared drive, the WhatsApp group with clients. Each one points at an activity.
• Interview the people who do the work for ten minutes each. They know where information goes.
• Use one spreadsheet, one row per activity, with the ten columns above. Do not build a system before the content exists.
• Mark the gaps as you go: no operator contract, no retention rule, a transfer with no ground. Those become the action list.

Keeping it true

A ROPA that reflects the business as it was two years ago is evidence against the business. Review it when a system changes, when a new product or service is launched, when an operator is appointed or replaced, and in any event once a year alongside the PAIA manual. Minute the review.

Where it fits

The ROPA sits in the POPIA compliance framework with the PAIA manual, the privacy notice, the operator contracts, the security safeguards, the breach procedure and the training record. RCC drafts and maintains these as part of governance frameworks and runs POPIA awareness training for the people whose daily work the ROPA describes.