Record of Processing Activities

The register at /privacy/ropa starts with active processing activities from the data map, then layers on the legal, organizational, and review facts that a technical source cannot decide. It supports internal combined exports and separate controller/processor exports aligned to GDPR Article 30 record structures.

Derived facts and human decisions

Derived from the data map: system, purpose/data use, data categories, data subjects, sensitive-data indicator, cross-border indicator, and source provenance.

Reviewed or added by your organization: activity role, purpose narrative, lawful basis, Article 9 condition, legitimate-interests assessment, data origin, recipients/vendors, retention, transfers and safeguards, security measures, owner, linked risks, assessment decision, status, and review date.

AI enrichment may draft some fields from verified source context. It remains a draft until accepted and is not a substitute for controller judgment.

Status and approval

• Derived: newly materialized and not yet substantively reviewed.
• In review: a person is completing and validating the record.
• Approved: an authorized reviewer signed off the record as it stood at that time.

Approval records the approver/time and freezes a snapshot of source-derived facts. If name, data use, categories, subjects, sensitive-data status, or cross-border status later changes, the row shows Changed since approval. The approval is still historical fact, but the record is no longer treated as currently ready until it is reviewed and approved again.

“Article 30 ready” requires an approved record, no conditional gaps, a review date that is not overdue, and no approval drift. It is a completeness/readiness definition inside Noru, not a regulator's determination.

Conditional gaps

• every record needs a lawful basis for readiness
• sensitive/special-category processing needs the relevant condition recorded
• legitimate interests needs a balancing-test narrative
• cross-border activities should record destination, mechanism, recipient, and safeguards
• processor-role records should identify the controller(s) they process for

Assessment recommendation and the human assessment required decision are separate. A recommendation is a triage signal; a completed assessment contains the decision and analysis.

Working with the register

1. Filter for derived, in-review, unowned, overdue, missing-basis, sensitive, transfer, or approval-drift rows.
2. Open a record and verify source facts against architecture and business practice.
3. Add the owner, role, narrative, lawful basis, origin, retention, recipients, transfers, and measures.
4. Link material organizational risks and open/complete an assessment where necessary.
5. Move to in review, perform an independent check, then approve and set the next review date.
6. Export the whole register or the filtered view in combined, controller, or processor mode.

Bulk actions can assign owner, lawful basis, role, review date, and status, but they should only be used when the same judgment genuinely applies to every selected record.

Relationships

• Vendor recipients are linked from the vendor register with role and provenance.
• Security measures can map to controls, connecting RoPA declarations to the control/evidence system.
• Linked risks remain scored and treated in the central risk register.
• Assessments link evidence and risks to the processing decision.
• Source updates create review work through approval drift and the Privacy Review queue.