Most privacy teams approaching Cambodia's Personal Data Protection Law (PDPL) for the first time make the same mistake. They open a spreadsheet, sketch a column for every field the law mentions, and start interviewing departments. Six months later they have a partial map of a moving organisation, no one agrees on the column definitions, and the next regulator request asks for the one piece nobody captured.
The work itself isn't hard. The trap is treating Records of Processing Activities (ROPA) as a documentation exercise rather than an operational control. This post walks through a tighter approach: what the record actually needs to contain under the PDPL, how to scope a first pass, where teams usually waste time, and what "good enough to defend in front of a regulator" looks like in practice.
Why ROPA exists in the first place
Cambodia's PDPL — like the GDPR before it — assumes that organisations processing personal data should be able to describe, on demand, what data they hold, why they hold it, who can access it, where it goes, and how long they keep it. The record is not paperwork for its own sake. It is the foundation for almost every other obligation the law imposes: lawful basis analysis, transfer impact assessments, breach notifications, data subject requests, retention enforcement, and vendor due diligence all read from the same underlying map.
When the record is wrong or stale, those obligations break quietly. A DSAR arrives, the team can't find every system that holds the requester's data, an overlooked SaaS retains the record beyond its deletion deadline, and a regulator notices on the next audit cycle. None of those failures look like ROPA problems. They are ROPA problems.
What the law actually asks for
The PDPL's record-keeping obligations are close in spirit to GDPR Article 30. For every processing activity, you should be able to answer:
- Purpose. Why does this activity exist? Specific is better than generic. "Send the monthly newsletter to opted-in users" is workable; "marketing" is not.
- Lawful basis. Consent, contract, legal obligation, vital interest, public task, or legitimate interest. Pick one and write down why.
- Categories of data and data subjects. The fields and the people. Note any special categories (health, biometric, financial) separately — they carry stricter rules.
- Recipients and processors. Internal teams that touch the data, external vendors that process on your behalf, and any onward transfers. Tie each to a contract or DPA.
- Cross-border transfers. If data leaves Cambodia, document the destination country, the transfer mechanism, and any safeguards.
- Retention. How long, and what triggers deletion. Indefinite is not an answer.
- Security measures. A short description of the controls that protect the activity — not a copy of the security policy.
If you can answer those seven questions for every meaningful processing activity in the organisation, you have a defensible record. Anything beyond that is decoration.
Each row in the record traces from a stated activity through the data it touches to the evidence that backs it up. The trail is what auditors read.
A three-step pass that finishes in a week
The fastest way to build a first record is to resist the urge to be exhaustive on day one. Most organisations have between fifteen and forty distinct processing activities once you collapse near-duplicates. Aim for breadth in week one; come back for depth in week two.
1. Scope the business units
Pick the smallest set of teams whose processing activities are material. For most companies that's HR, marketing, customer support, and engineering or product. Finance and procurement usually inherit from a smaller set of systems and can be folded in once the others are mapped.
Don't try to map the whole org by interviewing it. Start from the systems — the HR platform, the CRM, the support tool, the email service provider, the analytics suite. Each system implies a small number of activities and a small number of data categories. Cataloguing systems first compresses the interview load by an order of magnitude.
2. Map activities, not systems
This is where most spreadsheets go wrong. The unit of analysis is the activity, not the system. A single CRM hosts multiple activities (lead nurture, deal management, support history, marketing automation). A single activity often spans multiple systems (a hire spans the HR platform, the payroll system, the equipment provisioner, and the cloud identity directory).
For each activity, fill in the seven fields from the previous section. Keep the descriptions short and specific — the record is meant to be read, not filed.
3. Attach evidence in line
Every row should link to at least one piece of evidence: a DPIA where the risk merited one, a contract or DPA with the processor, a transfer mechanism, a retention schedule. If nothing exists, that absence is the gap that goes into the remediation log.
Resist the temptation to write the DPIA in week one. Note the gap, finish the breadth pass, then prioritise. A regulator inspection that finds an incomplete-but-honest record with documented gaps is a much better story than a polished record that turns out to be wrong under questioning.
What "audit-ready" looks like on paper
A defensible record shows three properties at a glance.
Completeness. No business unit conspicuously missing. The largest sources of personal data — HR, marketing, customers — are mapped. Each activity has the seven fields filled in.
Recency. Every entry has a "last reviewed" date within the last quarter. Stale records are worse than incomplete records, because they create a false sense of coverage. Build a review cadence and stick to it; a calendar reminder is more reliable than good intentions.
Traceable evidence. Each row links to a document — a DPIA, a contract, a transfer assessment, a retention schedule. Auditors don't read the record in isolation; they sample rows and follow the trail. If the trail leads nowhere, the row is a problem regardless of how well it's written.
A useful test: pick three random activities from the record and ask someone unfamiliar with them to follow the evidence trail. If they can tell you what data is involved, where it goes, and why it's lawful inside ten minutes, the record is doing its job.
Common ways the first pass goes wrong
A short list of patterns we see repeatedly.
- Mapping systems instead of activities. A row called "Salesforce" is not a record of processing. It's a hint that there are six or seven activities hiding inside it.
- Conflating controller and processor activities. When you process on behalf of someone else (say, as a SaaS provider handling customer data), those activities belong in a separate processor record with a different field set. Mixing them confuses everyone.
- Outsourcing the record to legal. Legal teams own the framework; they do not own the operational reality of every business unit. The record must be co-written with the teams doing the processing, or it will drift from reality within a quarter.
- Treating it as a one-time deliverable. ROPA is a living artifact. Build the review cadence into the workflow — quarterly is usually enough for low-volatility activities, monthly for fast-changing ones.
What to do this quarter
If you don't have a record yet, the smallest useful first step is to catalogue the systems that hold personal data, then map activities outward from each system. Three workdays, two collaborators, breadth over depth.
If you have a record but it hasn't been touched in six months, the most valuable next step is the recency pass: walk every entry, confirm or update the seven fields, mark the review date, and log the changes. The exercise usually surfaces between five and fifteen activities the team didn't know had drifted.
PDPL enforcement in Cambodia is still ramping up, but the trajectory is the same one every other jurisdiction has followed. A defensible record is the single artifact most likely to determine how an inspection goes. The investment is small. The downside of skipping it isn't.
Note: this is a sample post included with the Privexus blog system to illustrate the MDX format. Replace it with editorial content before launch.