Skip to main content

​
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.
Alle Endpunkte unten sind ge-rooted auf 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