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.
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).
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.
Returns 201 Created with the activity and a screening block:
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:
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.
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.
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.
