A free, copy-ready RoPA template with every GDPR Article 30 field and an example row. How to fill it in - and how Strac auto-populates the hard columns (what data, where) from real scans so it stays accurate.
Article 30 of the GDPR requires most organizations to maintain a Record of Processing Activities. Use the template below as your starting structure — it includes every field a controller RoPA needs. Copy it into a spreadsheet and complete one row per processing activity.
| RoPA field | What to record | Example |
|---|---|---|
| Processing activity | The business process | Customer billing |
| Controller / contact | Who’s responsible + DPO contact | Acme Ltd — dpo@acme.com |
| Purpose of processing | Why you process the data | Invoicing and payment |
| Categories of data subjects | Whose data | Customers |
| Categories of personal data | What data | Name, email, billing address, card token |
| Recipients | Who receives it | Payment processor, accounting SaaS |
| Third-country transfers | Any transfers + safeguard | US — Standard Contractual Clauses |
| Retention period | How long kept | 7 years (tax law) |
| Security measures | Technical/org safeguards | Encryption, access control, DLP |
For processor activities (data you handle on behalf of others), GDPR requires a slightly different set of fields — keep a separate processor RoPA. See our full data inventory and RoPA guide for the controller-vs-processor distinction.
Filling in the template once is easy. The reason RoPAs fail audits is step 2 — knowing what personal data each system actually holds — and step 6 — keeping it current. Both are impossible to do reliably by hand. This is where Strac changes the game: it discovers and classifies the personal data across your SaaS, cloud, databases, and endpoints, so the “categories of personal data” and “location” columns fill themselves — and stay current as data moves.
You get the structure from the template above; you get the accurate content from Strac. See how the underlying data inventory works, or how it maps to GDPR data mapping.
A RoPA template is a ready-made structure for the Record of Processing Activities that GDPR Article 30 requires. It lays out every field - purpose, data categories, recipients, transfers, retention, and security measures - so you can fill in one row per processing activity.
For most organizations, yes. GDPR Article 30 requires controllers and processors to maintain a Record of Processing Activities. The main exemption is for organizations under 250 employees that process data only occasionally and not sensitive data - a narrow carve-out.
A controller RoPA documents processing you decide the purposes of; a processor RoPA documents data you handle on behalf of clients. GDPR requires slightly different fields for each, so keep them separate.
Not because of the template - because the content is wrong. Teams can’t reliably list what personal data each system holds by hand, and the RoPA goes stale as data changes. Automated discovery keeps the ‘what data / where’ columns accurate.
The structure is a template, but the content - what personal data you hold and where - can be discovered automatically. Strac scans your systems, classifies the data, and populates and updates the underlying inventory, so your RoPA stays accurate.
Related: automated data mapping and data flow mapping.
A RoPA template gives you the structure in five minutes. The real work — and the reason RoPAs fail — is filling in what data you hold and keeping it current. Strac does that part automatically. Copy the template above to start, then book a demo to auto-populate and maintain it.
.avif){kind=icon}
.gif)
.webp)
