DSGVO-Verarbeitungsregister (ROPA + DPIA)
ROPA (Record of Processing Activities) und DPIA (Data
Protection Impact Assessment) sind die Selbst-Dokumentationsseite der
DSGVO. Wo ein DSAR das what
Datenobjekt anfragt covers, deckt das Register das, was Ihre
Organisation über sich selbst aufschreiben muss — bevor eine Anfrage
eintrifft.
Diese Seite beschreibt Orbits Plattformkontrollen. Sie ist keine
Rechtsberatung. Ob Sie ein Controller oder Processor sind, welche
Aktivitäten hochriskant sind und was Ihr Register enthalten muss,
hängt von Ihrer Verarbeitung ab. Bestätigen Sie mit qualifiziertem
Rechtsbeistand.
https://api.orbit.devotel.io/api/v1/compliance.
Was Art. 30 und Art. 35 verlangen
DSGVO Art. 30 verlangt, dass jeder Controller (und jeder Processor)
ein Protokoll seiner Verarbeitungsaktivitäten hält. Für jede Aktivität
namen das Protokoll den Zweck, die Kategorien von Datenobjekten
und Daten, die Empfänger, jede Cross-Border-Transfers und
ihre Schutz, die Aufbewahrungsdauer und die Sicherheitsmaßnahmen.
Ein Aufsichtsbehörde kann das Protokoll auf Anfrage für Art. 30(4)
verlangen.
DSGVO Art. 35 verlangt eine DPIA vor Verarbeitung, die
wahrscheinlich hochriskant ist — automated decision-making mit
wesentlichen Effekten, groß-scale Verarbeitung von special-category-
Daten oder systematic Monitoring öffentlich zugänglicher Gebiete. Die
Assessment-Records necessity und proportionality, die Risiken
identifiziert, die mitigations, das Residual-Risiko und das Ergebnis.
Orbit screens jede Aktivität, die Sie eingeben, gegen die Art. 35(3)-
Trigger und flaggt, ob eine DPIA erforderlich ist — und blockiert die
Aktivierung einer flagged-Aktivität, bis die DPIA aufgezeichnet ist
(siehe Status-Lebenszyklus).
Das Register ist Ihres — Orbit hält es, es nie füllt es
Das Register dokumentiert Ihre Organisations-
Verarbeitung. Orbit liefert den Speicher, den Status-Lebenszyklus,
das DPIA Screening und den Audit-ready-Export — es nie entscheidet,
was Ihre Rechtsgrundgrund ist oder was Ihre Aufbewahrungsdauer sein
sollte. Jede Aktivität wird erstellt, weitergeführt und assessed von
Ihrem eigenen Team, zu wie Regulatoren Art. 30 lesen: das Register
muss die Controller-eigene Kenntnis widerspiegeln.
Jede Aktivität erhält bei Eingabe eine menschliche Referenz (zum
Beispiel ROPA-2026-0004), sodass Sie sie in Ihren internen
Policies und in Korrespondenz mit einer Behörde zitieren können.
Verarbeitungsaktivitäten aufzeichnen
Eine Aktivität erstellen
POST /compliance/processing-activities — braucht ein Admin- oder
Owner-API-Key. Die Aktivität landet im Status draft.
Gibt 201 Created mit der Aktivität und einem screening-Block zurück:
Das DPIA-Screening
Jedes POST, GET, PATCH und PUT …/dpia Antwort enthält einen
screening-Block. Es flagged die Art. 35(3)-Trigger deterministisch:
automated_decision_making: true → automated decision-making mit
rechtlichen oder ähnlich signifikanten Effekten (Art. 35(3)(a)).systematic_monitoring: true → systematic Monitoring eines
öffentlich zugänglichen Bereichs (Art. 35(3)(c)).- Non-empty
special_categories zusammen mit large_scale: true →
groß-scale Verarbeitung von special categories (Art. 35(3)(b)).
- Ein Alleine-Vorkommen eines special-category- oder large-scale-Flags
erscheint trotzdem als ein High-Risk-Indicator (Art. 9 /
Art. 35(1)).
screening.required: true bedeutet, dass eine DPIA aufgezeichnet
werden muss, bevor die Aktivität zu active bewegen kann.
Status-Lebenszyklus
Eine Aktivität durchläuft:
draft → active → under_review → retired
PATCH /compliance/processing-activities/{id} aktualisiert mutable
Felder und/oder rückt den Status vor:
Eine Aktivität, deren Screening eine DPIA-Anforderung flagged, wird
mit 409 Conflict abgelehnt, bis eine DPIA aufgezeichnet wurde, deren
Ergebnis nicht do_not_proceed ist. Das macht das Register präventiv —
hochriskante Verarbeitung kann nicht unprotokolliert gehen.
Das Register lesen
GET /compliance/processing-activities — das ganze Register plus
einen Zusammenfassung: Zählungen nach Status, wie viele Aktivitäten
der Screen als DPIA-required flaggt (dpiaRequired), wie viele
davon noch keine aufgezeichnete DPIA haben (dpiaMissing) und wie
viele aufgezeichnete DPIAs auf einen high-Residual-Risiko fielen
(highResidualRisk).GET /compliance/processing-activities/{id} — eine Aktivität mit
ihrem Screening und, sobald aufgezeichnet, ihrer DPIA.
Eine DPIA aufzeichnen
PUT /compliance/processing-activities/{id}/dpia — braucht ein Admin-
oder Owner-API-Key. Zeichnet (oder ersetzt) die Art. 35-Assessment
für die Aktivität.
consult_authority mapped auf die Art. 36-Prior-Consultation-Pflicht,
geschuldet wenn ein high-Residual-Risiko nicht mitigiert werden kann.
Ein Ergebnis von do_not_proceed blockiert die Aktivierung der
Aktivität — lassen Sie es nur, wenn die Assessment schließlich
schließt, dass die Verarbeitung rechtmäßig nicht gehen kann.
Jede DPIA zeichnet, wer assessed und wann (assessedAt, assessedBy).
Das Art. 30-Inventar exportieren
GET /compliance/processing-activities/inventory gibt das ganze
Register serialisiert in der Audit-ready-Form zurück — das Attachment,
das ein DPO einem Aufsichtsbehörde auf einer Art. 30(4)-Anfrage
übergibt oder an einen Auditor-Evidence-Request attached.
Jedes Datensatz trägt seinen DPIA-Zustand — dpiaRequired,
dpiaRecorded, dpiaOutcome, residualRisk — sodass das Inventar
sich als Evidenz verdoppelt, dass hochriskante Verarbeitung gescreent
und assessed wurde.
Zugriffskontrolle
Reads (GET) sind für jedes authentifizierte Mitglied Ihrer
Organisation offen. Writes (POST, PATCH, PUT …/dpia) sind
Ernst auf Owner und Admin-Rollen — das Register ist ein
regulatorisches Kontrolle, in Einklang mit dem Rest der
Compliance-Schreibfläche (Breach-Incidents, Aufbewahrungs-Policy).
Jedes Intake, Update und DPIA-Aufzeichnung ist in Ihrem Audit-Log
mit dem Actor, der Aktivitäts-Referenz und dem Ergebnis geschrieben.
Verwandte Referenzen
