This RoPA template helps document the Article 30 fields that controllers and processors must be able to maintain in writing and make available to a supervisory authority on request.
The template separates controller and processor records, then turns purposes, data-subject categories, personal-data categories, recipients, transfers, erasure time limits, and security measures into usable evidence fields.
Structured answer sets in this page tree.
Cited legal and guidance references.
A GDPR record of processing activities () should be a self-contained inventory of real processing, not a policy reference or a list of systems. A controller decides the purposes and essential means of an activity; a processor handles personal data on a controller's behalf. Decide the organisation's role for each activity, then complete the Article 30 fields for that role. Article 30(5) is not a blanket exemption for organisations with fewer than 250 employees: the affected processing must still be recorded if it is likely to risk people's rights and freedoms, is not occasional, or includes Article 9 special-category data or Article 10 criminal-conviction and offence data.
Keep one row per processing activity or sub-activity. The row should be granular enough for an external reader to understand why the data is used, whose data is involved, which data categories are processed, who receives it, whether it leaves the EEA or goes to an international organisation, how long it is kept, and which security measures protect it.
Mark Article 30 fields separately from helpful extra fields. Lawful basis, special-category condition, risk rating, DPIA reference, breach reference, and transfer mechanism can make the record more useful, but they should not hide the prescribed Article 30 information. If an organisation relies on Article 30(5), record the employee-count basis and assess each affected activity against the risk, occasional-processing, Article 9, and Article 10 conditions rather than applying one organisation-wide label.
Processors need a different Article 30 record. Do not reuse the controller template without changing the row logic: a processor row should start with the controller on whose behalf the processing is carried out and the categories of processing performed for that controller.
A processor record can still use many of the same evidence fields, but the role statement must show that the processor is processing on behalf of a controller and that the row is organised around the controller served.
Complete the role assessment before filling the template. Under the GDPR, a controller determines the purposes and means of processing; a processor processes personal data on behalf of a controller; joint controllers jointly determine purposes and means for the relevant processing.
Where the same vendor relationship includes multiple roles, create separate rows. For example, one service may process support-ticket content as a processor while another recipient uses payment or banking data for its own controller purpose.
Use these row patterns as evidence prompts, then replace the examples with the organisation's actual facts. Avoid entries such as personal data, internal, appropriate security, or as per retention policy unless the row also states the concrete data, recipients, measures, and retention rule.
The record should be readable without opening internal folders. If a policy, contract, DPIA, transfer impact assessment, or retention schedule is linked, the row should still summarize the relevant field and identify who can produce the supporting document.
Before relying on the , test the fields that usually fail first: transfers, retention, and security. These fields should not be buried in linked documents or left as unexplained shorthand.
A usable Article 30 record should let privacy, legal, security, vendor management, and product owners answer the same questions from the same row: what processing is happening, why it is happening, who receives the data, where it goes, when it is erased, and how it is protected.
Use separate controller and processor tables even when the same organisation has both roles. Keep stable identifiers so related notices, lawful-basis records, LIAs, DPIAs, contracts, transfer assessments, retention rules, security evidence, incidents, and rights requests can point to the same activity without replacing the Article 30 fields.
Treat each row as controlled data. Record who supplied and approved each material fact, when it was checked, and which change events reopen it. Archive superseded rows with their effective dates so a reviewer can reconstruct what processing occurred during an earlier period.
Use a row that has one coherent role, purpose, people-and-data scope, recipient pattern, transfer position, retention rule, and security description. Split the row when a material difference would make any of those fields misleading or too generic.
Article 30(5) limits the obligation only for processing that is not likely to risk rights and freedoms, is occasional, and does not include Article 9 or Article 10 data. Assess processing activities against those conditions. A single triggering condition removes the derogation for the affected processing.
The row should state the required information itself. A link can provide supporting detail, but the maintained record should remain self-contained, readable, and available to the supervisory authority without requiring access to an internal drive or reconciliation of several documents.
Mark the activity retired and record its end date, then retain an appropriately controlled archive where accountability needs require it. Keep the live view current while preserving enough history to show what processing occurred and which rule applied at the time.
Sorena can help convert systems, vendors, products, and processing purposes into Article 30 rows with cited sources, owner assignments, retention fields, transfer fields, and evidence prompts.
Ask questions tied to cited sources about Article 30 fields, controller and processor roles, transfers, retention, and security measures using the cited sources on this page.
Review your RoPA structure, source gaps, and evidence fields with Sorena.
"Standard Contractual Clauses"
"RoPA should be a standalone record"
"shall maintain a record of processing activities"