> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

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

> Walk Settings → Compliance → Privacy register: intake a GDPR Article 30 processing activity, read the Article 35(3) DPIA screening result, record the assessment, advance the lifecycle, and export the audit-ready Art.30 inventory into your evidence binder.

# 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](/compliance/privacy-register). This page is the operator's walkthrough of the console.

<Note>
  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.
</Note>

***

## 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:

| Field                                         | Why it's there                                                                                                                     |
| --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| **Name** + **Description**                    | Identify the processing. Required.                                                                                                 |
| **Purpose** (Art.30(1)(b))                    | Why the personal data is processed. Required.                                                                                      |
| **Controller role**                           | Controller, joint controller, or processor.                                                                                        |
| **Lawful basis (Art.6)**                      | One of the six Art.6(1) bases — consent, contract, legal obligation, vital interests, public task, legitimate interests. Required. |
| **Data subject categories** (Art.30(1)(c))    | Who the data is about — customers, prospects, employees. One per line.                                                             |
| **Data categories** (Art.30(1)(c))            | What the data is — contact details, usage logs, audio recordings. One per line.                                                    |
| **Special categories (Art.9)**                | Health data, biometrics, ethnicity — leave empty if none. Feeds the DPIA screen. One per line.                                     |
| **Recipients** (Art.30(1)(d))                 | Categories of recipients the data is disclosed to. One per line.                                                                   |
| **Retention period** (Art.30(1)(f))           | Free-text policy reference — "24 months after contract end".                                                                       |
| **Security measures** (Art.30(1)(g) / Art.32) | Encryption at rest, access controls, audit logging. One per line.                                                                  |
| **Cross-border transfers** (Art.30(1)(e))     | Toggle for transfers outside the EEA; reveals the **Transfer safeguard** field (SCCs, adequacy decision, BCRs).                    |

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](/guides/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](/guides/compliance-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.

***

## Cross-links to the compliance fold

| Console surface                 | Path                                            | Where it's documented                                                      |
| ------------------------------- | ----------------------------------------------- | -------------------------------------------------------------------------- |
| Privacy register (ROPA + DPIA)  | Settings → Compliance → Privacy register        | This guide; the [privacy register reference](/compliance/privacy-register) |
| DSAR + breach-incident register | Settings → Compliance → DSAR / Breach incidents | [Its sister guide](/guides/compliance-dsar-breach-register)                |
| Evidence binder                 | Settings → Compliance → Binder                  | [Assemble and seal an evidence binder](/guides/compliance-evidence-binder) |
| Audit log                       | Settings → Audit log                            | [Audit log guide](/guides/audit-log)                                       |

## Related

* [GDPR Processing Register (ROPA + DPIA)](/compliance/privacy-register) — endpoint surface, field schemas, the screening rules
* [DSAR + breach-incident register](/guides/compliance-dsar-breach-register) — the sister walkthrough
* [Assemble and seal an evidence binder](/guides/compliance-evidence-binder) — where the export files
* [GDPR posture guide](/compliance/gdpr-posture-guide) — where the register sits in the sequence
* [Audit log](/guides/audit-log) — where every register write lands