PDPL Records of Processing Activities (RoPA): What to Include and How to Structure the Template

WaqiSec Compliance Team · Last reviewed: 2026-10-01

What is a record of processing activities under the PDPL?

A record of processing activities (RoPA) is an internal register that lists each way your organization uses personal data: why, about whom, which data, who receives it, where it goes and how long you keep it. In Arabic regulatory language it is سجل أنشطة معالجة البيانات الشخصية.

The duty sits in two places. Article 31 of the PDPL requires the controller to keep the record. Article 33 of the Implementing Regulations sets the detail: the minimum fields, the retention period and SDAIA's right to see it. Keep the two numbers apart, since some summaries cite "Article 31 of the Regulations" for this, which is a different provision.

The RoPA is also the base layer for most other PDPL documents. Your PDPL privacy notice, your transfer safeguards and your breach assessments all draw on the same facts. If the record is wrong, those documents are usually wrong too.

What must a PDPL RoPA include? The 8 Article 33 fields

Article 33 lists the minimum content. You can add more columns, but not fewer.

SDAIA's guideline includes a template model. It is guidance, not a mandatory form, so you may use your own layout as long as it covers all eight fields.

RoPA template structure that works

The most usable RoPA is organized by processing activity, one row each. A row per system ("Salesforce", "Google Drive") hides the purpose, and the purpose is what the law asks about. A spreadsheet with these columns covers Article 33 and the questions SDAIA, auditors and enterprise clients usually ask next:

1. Activity ID and name
2. Business owner (department and person)
3. Purpose
4. Legal basis (consent, contract, legal obligation, vital interest, public interest or legitimate interest)
5. Data subject categories
6. Personal data categories, with a sensitive data flag
7. Source of the data
8. Systems and storage locations
9. Recipients (internal and external)
10. Processors used, and whether a data processing agreement is signed
11. Transfers outside Saudi Arabia: country, recipient, mechanism
12. Retention period and deletion method
13. Security measures
14. DPIA needed? (yes/no and reference)
15. Date of last review

Columns 4, 7, 10, 14 and 15 go beyond the Article 33 minimum. They are worth the effort: the legal basis feeds your privacy notice, and the DPIA flag links the record to Article 25 of the Regulations, which requires an impact assessment for sensitive data and other higher-risk processing.

Worked example: one RoPA row

An illustrative entry for a mid-sized Saudi company's payroll activity:

How long must the record be kept?

Article 33 requires the record to be kept for as long as the processing continues, plus five years counted from the end of that processing activity. The clock runs from when the activity stops, not from when data was collected. If you retire a recruitment system in 2027, keep its RoPA entry until 2032.

In practice, never delete rows. Mark them "closed" with an end date so the five-year history stays visible.

Do processors and small companies need a RoPA?

• Controllers: yes. Article 33 places the duty on the controller.
• Processors: the Regulations do not set a separate RoPA article for processors. Your processor contracts should still oblige them to give you the information your record needs, especially sub-processors and hosting locations.
• Small companies: the PDPL has no headcount exemption like the 250-employee carve-out in GDPR Article 30(5). A 20-person company that processes customer data needs a record too, though it may only have 8–15 rows.
• SDAIA access: you do not file the RoPA routinely. You must provide it when SDAIA asks, so keep it ready to export.

How to build your PDPL RoPA in 6 steps

1. List departments. HR, sales, marketing, customer service, finance, IT, operations.
2. Interview each owner for 30–45 minutes. Ask what personal data they collect, why, in which tools, and who they send it to.
3. Pull the system list from IT and finance. SaaS invoices reveal tools that interviews miss.
4. Fill one row per activity and mark the sensitive data (health, biometric, genetic, criminal and security data, religious or political belief, ethnic origin).
5. Check each transfer. Any tool hosted outside the Kingdom needs a transfer mechanism. See our guide to transferring personal data outside Saudi Arabia.
6. Assign a review cycle. Update the record when a new tool, vendor or purpose is added, and review it in full at least once a year.

Common RoPA mistakes

• Vague purposes such as "business operations" that no regulator will accept.
• One retention period for everything, when Article 33 asks for a period per data category where possible.
• Missing transfers: email, CRM, analytics and support tools hosted abroad are the usual blind spots.
• No owner, so the record is accurate on the day it was written and stale six months later.
• Copying a GDPR RoPA without adding Saudi specifics such as SDAIA transfer mechanisms and the five-year retention of the record itself.
• Treating the RoPA as the privacy notice. The RoPA is internal; the notice is what individuals see.

PDPL RoPA checklist

• Record organized by processing activity, one row each
• All 8 Article 33 fields completed for every row
• Sensitive data flagged and linked to a DPIA where needed
• Retention period set per data category
• Every transfer outside the Kingdom has a named mechanism
• Processors listed, with signed data processing agreements
• Owner and review date on every row
• Closed activities kept for 5 years after they end
• Exportable copy ready for an SDAIA request

The RoPA is one of the five core documents in our Saudi PDPL compliance guide.

Related guides

This guide is general information, not legal advice. Always check the official text from the relevant authority before making decisions.