Skip to main content

​
Run the privacy register — ROPA intake, DPIA screening, and the Art.30 export

Settings → Compliance → Privacy register is your organisation’s record of its own processing: a GDPR Article 30 Record of Processing Activities (ROPA) where each activity documents what you process and why, and an optional Article 35 Data Protection Impact Assessment (DPIA) attached to each activity the screening flags as high-risk. The register keeps the record, runs the screen, and exports the inventory — your organisation decides what it processes, on which lawful basis, and for how long. For the full endpoint surface and field schemas, read the privacy register reference. This page is the operator’s walkthrough of the console.
Every control here is tenant-owned: you intake the activity, you answer the screening questions, you record the DPIA and choose its outcome, and you decide when a flagged activity may go live. Devotel Orbit supplies the register and the screening — not legal advice. Confirm your obligations with your data protection officer or counsel.

​
What the register records

Each intake creates one processing activity — the Art.30 record — with two possible attachments:
  • The activity record (ROPA). Names the processing, its purpose, the controller role and lawful basis, the categories of data subjects and data, the recipients, retention, transfers, and security measures. Every activity gets a human reference at intake (for example ROPA-2026-0004) you can cite in policies and authority correspondence.
  • The DPIA (Art.35). Optional until the screen flags the activity as high-risk — then a recorded assessment with a qualifying outcome is a precondition for activation. The assessment records necessity and proportionality, the risks and mitigations, likelihood × severity, the residual risk, whether the DPO was consulted, and the outcome.
The register page header shows a summary grid — Activities, DPIA required, DPIA missing, High residual risk — so an unassessed exposure is visible on the page, not buried in a row.

​
Intake an activity (ROPA, Art.30)

Open Settings → Compliance → Privacy register and select Intake activity. A new activity lands in draft and the register screens it on save. The intake form carries every field Art.30 asks for: Four toggles feed the Art.35 screen:
  • Special categories (Art.9) — any non-empty entry is a high-risk indicator.
  • Large scale — Art.35(3)(b); combined with special categories it flags the large-scale processing class.
  • Automated decision-making — Art.35(3)(a) / Art.22: legal or similarly significant effects on the subject.
  • Systematic monitoring — Art.35(3)(c): of a publicly accessible area.
On save, the response tells you immediately what the screen concluded: a flagged activity toasts that it is high-risk and must carry an Art.35 DPIA before it can go live.

​
Read the screening result

Each row’s DPIA cell renders one of three states:
  • Recorded · <risk> — a DPIA is on file; the badge shows its residual risk.
  • Required · missing — a trigger fired (special categories, large scale, automated decision-making, or systematic monitoring) and no DPIA is recorded yet. The server blocks activation until you record one.
  • Not required — no Art.35(3) trigger fired; a DPIA is optional.
The summary grid counts DPIA required and DPIA missing across the register so an unassessed exposure is impossible to miss. Expand a row to see the full Art.30 record — purpose, lawful basis, subjects, data, recipients, transfers, retention, and the Art.35(3) triggers — plus the recorded DPIA block when one exists.

​
Record the DPIA (Art.35)

On the expanded row, select Record DPIA (or Re-assess DPIA when one is already on file). The dialog walks the Art.35(7) structure:
  1. Necessity & proportionality (Art.35(7)(b)) — required. Why the processing is necessary and proportionate to the purpose.
  2. Risks identified — one per line: unauthorised access, re-identification, retention beyond purpose.
  3. Mitigations (Art.35(7)(d)) — one per line: pseudonymisation, strict access logging, automated deletion.
  4. Likelihood × Severity — low / medium / high each.
  5. Residual risk — defaults to Automatic (matrix), which rates the remaining risk from the likelihood × severity pair; override it when you need to record a deliberate divergence.
  6. DPO consulted (Art.35(2)).
  7. Outcome — one of four: Proceed, Proceed with safeguards (the default), Consult supervisory authority — Art.36, or Do not proceed.
An outcome of Consult supervisory authority — Art.36 records the prior-consultation duty owed when a high residual risk cannot be mitigated. Do not proceed permanently blocks the activity from going active — leave it only when the assessment concludes the processing cannot lawfully go ahead. Re-assessing updates the assessment in place; both the assessor and the timestamp are recorded.

​
Advance the lifecycle

An activity moves through Draft → Active → Under review → Retired. Change the lifecycle from the status picker on the expanded row. One transition is gated: a high-risk activity (any Art.35(3) trigger fired) cannot move to Active until a DPIA is recorded whose outcome is not Do not proceed. The gate is what makes the register proactive — high-risk processing cannot go live undocumented. Every other transition is free; use Under review for the periodic re-assessment cadence your counsel sets, and Retired for processing that has ended.

​
Roles and access

Reads (the list, the summary, the export) are available to any authenticated member of your organisation. Every write — intake, status advance, DPIA recording — is restricted to the owner and admin roles, matching the rest of the compliance write surface. Each write lands in your audit log with the actor, the activity reference, and the outcome, so a regulator can reconstruct who recorded what.

​
Export the Art.30 inventory into your evidence binder

Select Export Art.30 ROPA on the page header. The register serialises every activity into the audit-ready inventory — one record per activity with its purpose, lawful basis, categories, recipients, retention, transfers, status, and DPIA state (dpiaRequired, dpiaRecorded, dpiaOutcome, residualRisk) — and downloads it as a dated JSON file (art30-ropa-inventory-YYYY-MM-DD.json). This is the document a DPO hands a supervisory authority on an Art.30(4) request. File it in your evidence binder alongside the DSAR deletion certificates and breach attestations, so the binder holds the register’s state at audit time rather than a stale snapshot.