> ## 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. # GDPR Processing Register (ROPA + DPIA) > Document your GDPR Art.30 Records of Processing Activities and record Art.35 Data Protection Impact Assessments in a tenant-owned register with an exportable audit inventory. # GDPR Processing Register (ROPA + DPIA) **ROPA** (Record of Processing Activities) and **DPIA** (Data Protection Impact Assessment) are the self-documentation side of GDPR. Where a DSAR covers what a data subject asks you for, the register covers what your organisation must write down about itself — before any request arrives. This page describes Orbit's platform controls. It is **not legal advice.** Whether you are a controller or processor, which activities are high-risk, and what your register must contain depend on your processing. Confirm with qualified counsel. All endpoints below are rooted at `https://api.orbit.devotel.io/api/v1/compliance`. *** ## What Art.30 and Art.35 demand **GDPR Art.30** requires every controller (and every processor) to keep a record of its processing activities. For each activity the record names the **purpose**, the **categories of data subjects and data**, the **recipients**, any **cross-border transfers and their safeguard**, the **retention period**, and the **security measures** applied. A supervisory authority can demand the record on request (Art.30(4)). **GDPR Art.35** requires a **DPIA** before processing that is likely to be high-risk — automated decision-making with significant effects, large-scale processing of special-category data, or systematic monitoring of publicly accessible areas. The assessment records necessity and proportionality, the risks identified, the mitigations, the residual risk, and the outcome. Orbit screens each activity you intake against the Art.35(3) triggers and flags whether a DPIA is required — and blocks activation of a flagged activity until the DPIA is recorded (see [Status lifecycle](#status-lifecycle)). ## The register is yours — Orbit keeps it, it never fills it The register documents **your** organisation's processing. Orbit supplies the storage, the status lifecycle, the DPIA screening, and the audit-ready export — it never decides what your lawful basis is or what your retention period should be. Every activity is created, advanced, and assessed by your own team, which matches how regulators read Art.30: the register must reflect the controller's own knowledge. Each activity gets a human reference on intake (for example `ROPA-2026-0004`) so you can cite it in your internal policies and in correspondence with an authority. *** ## Recording processing activities ### Create an activity `POST /compliance/processing-activities` — requires an admin or owner API key. The activity lands in status `draft`. ```bash theme={null} curl -X POST https://api.orbit.devotel.io/api/v1/compliance/processing-activities \ -H "X-API-Key: dv_live_sk_..." \ -H "Content-Type: application/json" \ -d '{ "name": "Customer support call recordings", "description": "Voice recordings of inbound support calls used for quality review and dispute resolution.", "purpose": "Quality assurance and dispute handling for support interactions.", "controller_role": "controller", "lawful_basis": "legitimate_interests", "data_subject_categories": ["customers", "prospects"], "data_categories": ["audio recordings", "caller number", "agent notes"], "special_categories": [], "recipients": ["support operations team"], "cross_border_transfers": false, "retention_period": "90 days after call, then deleted", "security_measures": ["encryption at rest", "role-restricted access", "audit logging"], "large_scale": false, "automated_decision_making": false, "systematic_monitoring": false }' ``` Returns `201 Created` with the activity and a `screening` block: ```json theme={null} { "id": "processingActivity_7kf2…", "reference": "ROPA-2026-0004", "status": "draft", "screening": { "required": false, "triggers": [] } } ``` | Field | Type | Notes | | --------------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | `name` | string | **Required.** 2–200 chars. | | `description` | string | **Required.** 2–8000 chars. | | `purpose` | string | **Required.** Art.30(1)(b). | | `controller_role` | enum | `controller` (default), `joint_controller`, `processor`. | | `lawful_basis` | enum | **Required.** One of `consent`, `contract`, `legal_obligation`, `vital_interests`, `public_task`, `legitimate_interests` (GDPR Art.6(1)). | | `data_subject_categories` | string\[] | Art.30(1)(c) — who the data is about. | | `data_categories` | string\[] | Art.30(1)(c) — what the data is. | | `special_categories` | string\[] | Art.9 special categories present — their presence feeds the DPIA screen. | | `recipients` | string\[] | Art.30(1)(d) — categories of recipients. | | `cross_border_transfers` | boolean | Art.30(1)(e) — transfers outside the EEA. | | `transfer_safeguard` | string | The Art.44–50 safeguard relied on (SCCs, adequacy, BCRs…). | | `retention_period` | string | Art.30(1)(f) — free-text policy reference. | | `security_measures` | string\[] | Art.30(1)(g) / Art.32 technical and organisational measures. | | `large_scale` | boolean | Feeds the Art.35 screen. | | `automated_decision_making` | boolean | Art.35(3)(a) trigger. | | `systematic_monitoring` | boolean | Art.35(3)(c) trigger. | ### The DPIA screening Every `POST`, `GET`, `PATCH`, and `PUT …/dpia` response includes a `screening` block. It flags the Art.35(3) triggers deterministically: * `automated_decision_making: true` → automated decision-making with legal or similarly significant effects (Art.35(3)(a)). * `systematic_monitoring: true` → systematic monitoring of a publicly accessible area (Art.35(3)(c)). * Non-empty `special_categories` together with `large_scale: true` → large-scale processing of special categories (Art.35(3)(b)). * A lone special-category or large-scale flag still surfaces as a high-risk indicator (Art.9 / Art.35(1)). `screening.required: true` means a DPIA must be recorded before the activity can move to `active`. ### Status lifecycle An activity moves through: `draft` → `active` → `under_review` → `retired` `PATCH /compliance/processing-activities/{id}` updates mutable fields and/or advances the status: ```bash theme={null} curl -X PATCH https://api.orbit.devotel.io/api/v1/compliance/processing-activities/processingActivity_7kf2… \ -H "X-API-Key: dv_live_sk_..." \ -H "Content-Type: application/json" \ -d '{ "status": "active" }' ``` Activating an activity whose screening flags a DPIA requirement is rejected with `409 Conflict` until a DPIA has been recorded whose outcome is not `do_not_proceed`. This is what makes the register proactive — high-risk processing cannot go live undocumented. ### Read the register * `GET /compliance/processing-activities` — the full register plus a summary: counts by status, how many activities the screen flags as DPIA-required (`dpiaRequired`), how many of those still have no recorded DPIA (`dpiaMissing`), and how many recorded DPIAs landed on a high residual risk (`highResidualRisk`). * `GET /compliance/processing-activities/{id}` — one activity with its screening and, once recorded, its DPIA. *** ## Recording a DPIA `PUT /compliance/processing-activities/{id}/dpia` — requires an admin or owner API key. Records (or replaces) the Art.35 assessment for the activity. ```bash theme={null} curl -X PUT https://api.orbit.devotel.io/api/v1/compliance/processing-activities/processingActivity_7kf2…/dpia \ -H "X-API-Key: dv_live_sk_..." \ -H "Content-Type: application/json" \ -d '{ "necessity_proportionality": "Call recording is limited to support lines; retention is capped at 90 days; access is restricted to the support operations team.", "risks_identified": ["Unauthorised access to recordings", "Retention beyond stated purpose"], "likelihood": "medium", "severity": "high", "mitigations": ["Role-restricted access", "Automated deletion at 90 days", "Access audit trail"], "residual_risk": "medium", "dpo_consulted": true, "outcome": "proceed_with_safeguards" }' ``` | Field | Type | Notes | | --------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | `necessity_proportionality` | string | **Required.** Art.35(7)(b). | | `risks_identified` | string\[] | Risks to the rights and freedoms of data subjects. | | `likelihood` | enum | **Required.** `low`, `medium`, `high`. | | `severity` | enum | **Required.** `low`, `medium`, `high`. | | `mitigations` | string\[] | Art.35(7)(d) — measures envisaged to address the risks. | | `residual_risk` | enum | Risk remaining after mitigations. Defaults to the likelihood × severity matrix rating when omitted. | | `dpo_consulted` | boolean | Art.35(2). | | `outcome` | enum | Art.35(7)(d) decision: `proceed`, `proceed_with_safeguards`, `consult_authority`, `do_not_proceed`. Defaults to `proceed_with_safeguards`. | `consult_authority` maps to the Art.36 prior-consultation duty owed when a high residual risk cannot be mitigated. An outcome of `do_not_proceed` blocks activation of the activity — leave it only when the assessment concludes the processing cannot lawfully go ahead. Each DPIA records who assessed it and when (`assessedAt`, `assessedBy`). *** ## Exporting the Art.30 inventory `GET /compliance/processing-activities/inventory` returns the whole register serialised to the audit-ready shape — the attachment a DPO hands to a supervisory authority on an Art.30(4) request, or attaches to an auditor's evidence request. ```bash theme={null} curl https://api.orbit.devotel.io/api/v1/compliance/processing-activities/inventory \ -H "X-API-Key: dv_live_sk_..." ``` ```json theme={null} { "generatedAt": "2026-08-24T09:30:00.000Z", "recordCount": 1, "records": [ { "reference": "ROPA-2026-0004", "name": "Customer support call recordings", "purpose": "Quality assurance and dispute handling for support interactions.", "controllerRole": "controller", "lawfulBasis": "legitimate_interests", "dataSubjectCategories": ["customers", "prospects"], "dataCategories": ["audio recordings", "caller number", "agent notes"], "specialCategories": [], "recipients": ["support operations team"], "crossBorderTransfers": false, "transferSafeguard": null, "retentionPeriod": "90 days after call, then deleted", "securityMeasures": ["encryption at rest", "role-restricted access", "audit logging"], "status": "draft", "dpiaRequired": false, "dpiaTriggers": [], "dpiaRecorded": false, "dpiaOutcome": null, "residualRisk": null } ] } ``` Every record carries its DPIA state — `dpiaRequired`, `dpiaRecorded`, `dpiaOutcome`, `residualRisk` — so the inventory doubles as evidence that high-risk processing was screened and assessed. *** ## Access control Reads (`GET`) are available to any authenticated member of your organisation. Writes (`POST`, `PATCH`, `PUT …/dpia`) are restricted to **owner** and **admin** roles — the register is a regulatory control, in line with the rest of the compliance write surface (breach incidents, retention policy). Every intake, update, and DPIA recording is written to your audit log with the actor, the activity reference, and the outcome. *** ## Related references * [Assembling a GDPR Posture End to End](/compliance/gdpr-posture-guide) — the sequence the register documents one stage of. * [Data Subject Access Requests (DSAR)](/compliance/dsar) — the other half of GDPR: receiving, verifying, and fulfilling subject access, erasure, and portability requests across GDPR, CCPA/CPRA, LGPD, PDPA, and DPDP. * [Consent Management](/compliance/consent-management) — record and look up the consent state an activity may rely on as its lawful basis. * [Opt-Out & Suppression Lists](/compliance/opt-out-suppression) — how erasure and opt-out outcomes flow into suppression. * [API Reference → Compliance](/api-reference/endpoints/compliance) — full request/response schemas (regenerated from the live API).