Article 30 RoPA Intake Workflow

Open a RoPA intake whenever a team creates, changes, or retires a processing activity that uses personal data. The intake should start before release, supplier onboarding, campaign launch, system migration, or material data-flow change so the Article 30 record can be updated while facts are still available from the teams making the change.

The first triage is the role. If the organisation determines the purposes and essential means of the processing, collect the controller record. If it processes personal data on behalf of another controller, collect the processor record for each controller. If purposes and means are determined jointly with another party, record the joint-controller details and the allocation of responsibilities separately.

Do not treat fewer than 250 employees as an organisation-wide exemption. Article 30(5) removes the record duty only for processing that is occasional, unlikely to risk individuals' rights and freedoms, and does not include Article 9 special-category data or Article 10 criminal-conviction and offence data. If the processing is not occasional, is likely to result in a risk, or includes Article 9 or Article 10 data, the affected processing belongs in the record. Record the exemption analysis per activity, including the facts and approving owner, instead of recording only the organisation's headcount.

For controller records, the intake must capture the controller identity and contact details, and where applicable the joint controller, controller representative, and data protection officer. The row should then describe the purpose, the categories of data subjects, the categories of personal data, the categories of recipients, transfers to third countries or international organisations, retention, and a general description of Article 32 security measures.

Article 30 asks for recipient categories, not necessarily every recipient's name, and for envisaged erasure time limits and a general security-measures description where possible. A named material recipient, lawful basis, Article 9 condition, DPIA link, transfer tool, and owner can improve accountability, but label those as supporting fields rather than changing the legal minimum.

Do not accept entries such as personal data, internal, as per policy, or appropriate security. The record should be understandable to an external reader without opening internal drives or reconciling multiple documents. If a linked policy is needed for more detail, the intake still needs the actual retention period or criteria and the security measures summary in the RoPA row.

For processor records, intake starts with the processor, each controller on whose behalf the processing is performed, and any applicable representatives or DPOs. The processor row should then state the categories of processing carried out for each controller, any third-country or international-organisation transfers, and the general Article 32 security measures.

The processor record does not use the controller field list. Article 30(2) requires the processor's and each controller's name and contact details, applicable representatives and DPO, processing categories for each controller, relevant transfers, and a general description of Article 32 measures where possible. Purposes, data-subject categories, personal-data categories, recipients, and erasure periods may still be needed in the Article 28 agreement or service evidence, but do not silently present them as processor-RoPA minimum fields.

The evidence package should let the controller and processor prove that the row reflects current processing. Store the processing agreement or instruction reference, sub-processor approval status, data location, transfer description, retention or deletion/return instruction, security-measure summary, and audit or information-sharing contact.

The RoPA intake should block closure until transfers, retention, and security are described at the level Article 30 requires and the linked operational evidence is assigned. A row that says yes for a third-country transfer but does not identify the country or international organisation is incomplete. A transfer review that omits the importer, role, Chapter V route, and evidence is also incomplete, even where those supporting details sit in a linked transfer file rather than the legal-minimum RoPA field.

For SCC-based transfers, keep the transfer description aligned with the SCC appendix evidence: parties and roles, purposes of the transfer, categories of data, retention period or criteria, security measures, and any supplementary safeguards or transfer assessment evidence. For security, describe measures that map to the activity rather than a generic statement that controls exist.

Close the intake only when the row can stand on its own. A privacy reviewer should be able to read a controller row and understand who controls the data, why it is used, what data and people are affected, the recipient categories, where it goes, the envisaged erasure periods where possible, and the general security measures. A processor row should identify each controller and the processing categories performed for it, along with the applicable transfer and security fields.

Use a defined status such as draft, blocked, approved, active, under review, or retired. Approval should record the decision date, named approvers, open exceptions, evidence locations, and next review trigger. Reopen the intake when a purpose changes, a new category of data subject or personal data is added, a recipient or sub-processor changes, a transfer destination or mechanism changes, a retention rule changes, a security measure materially changes, or a processing activity is retired.