Records of processing are the foundation of a privacy programme, not a bureaucratic afterthought. Every other obligation — subject access, retention, DPIAs, breach assessment, transfer mapping — depends on knowing what personal data you hold, why, where it lives and who else sees it.
The fields
As a controller, record for each processing activity:
- Name and purpose of the processing.
- Controller identity, and DPO or privacy contact.
- Categories of data subjects — customers, employees, applicants.
- Categories of personal data, flagging special category data explicitly.
- Lawful basis for each purpose.
- Recipients, including processors and any onward disclosure.
- International transfers and the safeguard relied on.
- Retention period, or the criteria used to determine it.
- General description of security measures.
As a processor, the list is shorter: the controllers you act for, categories of processing performed for each, transfers, and security measures.
Add two fields the law does not require but every practitioner needs: the system the data lives in, and a named business owner. Without them the record is unusable operationally — you cannot action a deletion request against a "purpose".
Keep processing records linked to controls
GRC Copilot keeps processing records, retention decisions and the security controls behind them together — so demonstrating compliance is a query, not a project.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
Building it without a year-long project
- Start from business processes, not systems. "Recruit staff", "bill customers", "run support". Systems attach underneath.
- Interview by function — HR, sales, marketing, support, finance, engineering. Each owns a handful of activities.
- Use the system inventory as a cross-check at the end, to find processing nobody mentioned.
- Accept a rough first pass. A complete record at moderate detail beats a perfect record covering a third of the organisation.
- Assign owners so maintenance is distributed rather than falling to one person.
Keeping it current
A ROPA written once and filed is worse than none, because it creates false confidence. Tie updates to events that actually happen: new system procurement, new processor, new product feature handling personal data, and organisational change. Add a light annual confirmation by each owner.
The gaps regulators find
- Marketing and analytics processing omitted entirely.
- Employee data forgotten because privacy work focused on customers.
- Retention "as long as necessary" — not a criterion, and treated as a non-answer.
- Transfers unmapped, particularly support access from other regions.
- Sub-processors of your processors, which flow down to you.
- Shadow systems bought on a departmental card.
Frequently asked questions
Do small organisations need a ROPA?
There are limited exemptions, but they are narrower than most assume — regular processing or special category data generally brings you in scope. Practically, you need the information regardless.
Is a spreadsheet acceptable?
Yes, if it is complete and current. The format is not prescribed; the maintenance is what fails.
Must we publish it?
No. It is produced to the regulator on request. Your privacy notice is the public-facing document.
How detailed should it be?
Detailed enough to action a subject request and answer a regulator. Granularity below that is effort without benefit.
Key takeaways
- Every other privacy obligation depends on the ROPA.
- Add system and named owner — the legal fields alone are not operationally usable.
- Build from business processes and cross-check against the system inventory.
- "As long as necessary" is not a retention criterion.