Article 30 of the GDPR requires controllers and processors to maintain a written record of their processing activities. The record is the operational inventory that proves the organization knows what data it has, why it has it, where it goes, and who it shares it with. It is one of the first artifacts a regulator asks for during an investigation.
The required content is specific. For controllers, the record covers the name and contact details of the controller, the purposes of processing, the categories of data subjects and personal data, the categories of recipients, transfers to third countries, retention periods, and a general description of security measures. For processors, the record covers similar fields scoped to the processing they do on a controller's behalf, including the controllers they act for and any sub-processors they engage.
In practice, the Records of Processing Activities (ROPA) lives in a spreadsheet, a privacy management platform, or a section of an internal wiki. Most mid-market organizations run it in a tool like OneTrust or DataGrail; smaller teams run it in a maintained spreadsheet. The format does not matter to the regulator. The currency does. A stale ROPA that names systems the company no longer uses is worse than no ROPA at all.
For SaaS vendors that act as processors, the ROPA discipline doubles as input to the customer-facing DPA and sub-processor list. Done well, it is the single source of truth that feeds every privacy artifact the company produces. Done poorly, it is a compliance theater document nobody trusts.