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.

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.

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 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 same level of specificity as the processing purpose. These fields often expose whether the record is useful: a row that says yes for a third-country transfer but does not identify the country, recipient role, safeguard, or transfer mechanism is not ready.

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 impact 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 the row and understand who controls or processes the data, why the data is used, what data and people are affected, who receives it, where it goes, how long it remains, and which security measures protect it.

Reopen the intake when a processing 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.