> ## 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. # DSGVO-Verarbeitungsregister (ROPA + DPIA) > Dokumentieren Sie Ihre DSGVO Art. 30-Records of Processing Activities und zeichnen Sie Art. 35 Data Protection Impact Assessments in einem Mandanten-eigenen Register mit einem exportierbaren Audit-Inventar. # 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](#status-lifecycle)). ## 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`. ```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": "Kundensupport-Anrufaufzeichnungen", "description": "Sprachaufzeichnungen eingehender Support-Anrufe, genutzt für Qualitätsreview und Streitbeilegung.", "purpose": "Qualitätssicherung und Streitbeilegung für Support-Interaktionen.", "controller_role": "controller", "lawful_basis": "legitimate_interests", "data_subject_categories": ["Kunden", "Prospects"], "data_categories": ["Audioaufzeichnungen", "Anrufernummer", "Agent-Notizen"], "special_categories": [], "recipients": ["Support-Ops-Team"], "cross_border_transfers": false, "retention_period": "90 Tage nach Anruf, dann gelöscht", "security_measures": ["Verschlüsselung aufhalt", "Roll-restricted Zugang", "Audit Logging"], "large_scale": false, "automated_decision_making": false, "systematic_monitoring": false }' ``` Gibt `201 Created` mit der Aktivität und einem `screening`-Block zurück: ```json theme={null} { "id": "processingActivity_7kf2…", "reference": "ROPA-2026-0004", "status": "draft", "screening": { "required": false, "triggers": [] } } ``` | Feld | Typ | Notizen | | --------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | `name` | string | **Erforderlich.** 2–200 Zeichen. | | `description` | string | **Erforderlich.** 2–8000 Zeichen. | | `purpose` | string | **Erforderlich.** Art. 30(1)(b). | | `controller_role` | enum | `controller` (default), `joint_controller`, `processor`. | | `lawful_basis` | enum | **Erforderlich.** Eines von `consent`, `contract`, `legal_obligation`, `vital_interests`, `public_task`, `legitimate_interests` (DSGVO Art. 6(1)). | | `data_subject_categories` | string\[] | Art. 30(1)(c) — über wen die Daten sind. | | `data_categories` | string\[] | Art. 30(1)(c) — was die Daten sind. | | `special_categories` | string\[] | Art. 9 special categories present — ihre Präsenz nährt den DPIA-Screen. | | `recipients` | string\[] | Art. 30(1)(d) — Kategorien von Empfängern. | | `cross_border_transfers` | boolean | Art. 30(1)(e) — Transfers außerhalb des EEA. | | `transfer_safeguard` | string | Der Art. 44–50 Schutz, auf den verlassen wird (SCCs, adequacy, BCRs…). | | `retention_period` | string | Art. 30(1)(f) — Freitext-Policy-Referenz. | | `security_measures` | string\[] | Art. 30(1)(g) / Art. 32 technische und organisatorische Maßnahmen. | | `large_scale` | boolean | Nährt den Art. 35-Screen. | | `automated_decision_making` | boolean | Art. 35(3)(a)-Trigger. | | `systematic_monitoring` | boolean | Art. 35(3)(c)-Trigger. | ### 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: ```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" }' ``` 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. ```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": "Anrufaufzeichnung ist auf Support-Linien begrenzt; Aufbewahrung ist auf 90 Tage gecapt; Zugang ist auf das Support-Ops-Team eingeschränkt.", "risks_identified": ["Unauthorisiertes Zugang zu Aufzeichnungen", "Aufbewahrung jenseits des angegebenen Zwecks"], "likelihood": "medium", "severity": "high", "mitigations": ["Roll-restricted Zugang", "Automatisierte Löschung bei 90 Tagen", "Zugangs-Audit-Trail"], "residual_risk": "medium", "dpo_consulted": true, "outcome": "proceed_with_safeguards" }' ``` | Feld | Typ | Notizen | | --------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | `necessity_proportionality` | string | **Erforderlich.** Art. 35(7)(b). | | `risks_identified` | string\[] | Risiken für die Rechte und Freiheiten von Datenobjekten. | | `likelihood` | enum | **Erforderlich.** `low`, `medium`, `high`. | | `severity` | enum | **Erforderlich.** `low`, `medium`, `high`. | | `mitigations` | string\[] | Art. 35(7)(d) — Maßnahmen, die envisagitiert, um die Risiken zu adressieren. | | `residual_risk` | enum | Risiko verbleibend nach mitigations. Defaults auf die Likelihood × Severity Matrix-Rating, wenn omittt. | | `dpo_consulted` | boolean | Art. 35(2). | | `outcome` | enum | Art. 35(7)(d)-Entscheid: `proceed`, `proceed_with_safeguards`, `consult_authority`, `do_not_proceed`. Defaults auf `proceed_with_safeguards`. | `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. ```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": "Kundensupport-Anrufaufzeichnungen", "purpose": "Qualitätssicherung und Streitbeilegung für Support-Interaktionen.", "controllerRole": "controller", "lawfulBasis": "legitimate_interests", "dataSubjectCategories": ["Kunden", "Prospects"], "dataCategories": ["Audioaufzeichnungen", "Anrufernummer", "Agent-Notizen"], "specialCategories": [], "recipients": ["Support-Ops-Team"], "crossBorderTransfers": false, "transferSafeguard": null, "retentionPeriod": "90 Tage nach Anruf, dann gelöscht", "securityMeasures": ["Verschlüsselung aufhalt", "Roll-restricted Zugang", "Audit Logging"], "status": "draft", "dpiaRequired": false, "dpiaTriggers": [], "dpiaRecorded": false, "dpiaOutcome": null, "residualRisk": null } ] } ``` 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 * [Eine DSGVO-Posture-End zu Ende zusammenbauen](/compliance/gdpr-posture-guide) — die Sequenz, die das Register ein Stadium von dokumentiert. * [Datenobjekt-Zugangs-Anfragen (DSAR)](/compliance/dsar) — die andere Hälfte von DSGVO: das Empfangen, Verifizieren und Erfüllen von Subject-Access-, Erasure- und Portability-Anfragen über DSGVO, CCPA/CPRA, LGPD, PDPA und DPDP. * [Consent Management](/compliance/consent-management) — aufzeichnen und aussehen den Consent-Zustand, den eine Aktivität als ihre Rechtsgrundlage anrufen kann. * [Opt-Out & Unterdrückungslisten](/compliance/opt-out-suppression) — wie Erasure- und Opt-Out-Ergebnisse in Unterdrückung fließen. * [API-Referenz → Compliance](/api-reference/endpoints/compliance) — volle Request/Response-Schemas (aus der Live-API regeneriert).