Registro de tratamiento GDPR (ROPA + DPIA)
El ROPA (Record of Processing Activities) y la DPIA (Data Protection
Impact Assessment) son el lado de auto-documentación del GDPR. Donde un DSAR
cubre lo que un interesado le solicita, el registro cubre lo que su
organización debe escribir sobre sí misma — antes de que llegue cualquier solicitud.
Esta página describe los controles de plataforma de Orbit. No es
asesoramiento legal. Si usted es responsable o encargado, qué actividades
son de alto riesgo y qué debe contener su registro depende de su
tratamiento. Confirme con un asesor cualificado.
https://api.orbit.devotel.io/api/v1/compliance.
Lo que exigen el Art. 30 y el Art. 35
El Art. 30 del GDPR exige que todo responsable (y todo encargado) mantenga un
registro de sus actividades de tratamiento. Para cada actividad, el registro nombra el
propósito, las categorías de interesados y de datos, los
destinatarios, cualquier transferencia transfronteriza y su garantía, el
periodo de retención y las medidas de seguridad aplicadas. Una
autoridad de supervisión puede exigir el registro a solicitud (Art. 30(4)).
El Art. 35 del GDPR exige una DPIA antes de un tratamiento que probablemente sea
de alto riesgo — toma de decisiones automatizada con efectos significativos,
tratamiento a gran escala de datos de categorías especiales, o monitorización
sistemática de zonas públicamente accesibles. La evaluación registra necesidad y
proporcionalidad, los riesgos identificados, las mitigaciones, el riesgo residual y el resultado.
Orbit filtra cada actividad que usted presenta contra los disparadores del Art. 35(3) y
marca si se requiere una DPIA — y bloquea la activación de una actividad
marcada hasta que la DPIA se registre (vea Ciclo de vida de estado).
El registro es suyo — Orbit lo guarda, nunca lo rellena
El registro documenta el tratamiento de su organización. Orbit suministra
el almacenamiento, el ciclo de vida de estado, el filtrado de DPIA y la
exportación lista para auditoría — nunca decide cuál es su base jurídica o cuál debería ser
su periodo de retención. Cada actividad la crea, avanza y evalúa
su propio equipo, lo que coincide con cómo los reguladores leen el Art. 30: el registro debe
reflejar el conocimiento propio del responsable.
Cada actividad recibe una referencia humana al presentarse (por ejemplo
ROPA-2026-0004) para que usted la pueda citar en sus políticas internas y en
correspondencia con una autoridad.
Registrar actividades de tratamiento
Crear una actividad
POST /compliance/processing-activities — requiere una clave API de
administrador u owner. La actividad aterriza en estado draft.
Devuelve 201 Created con la actividad y un bloque screening:
El filtrado de DPIA
Toda respuesta de POST, GET, PATCH y PUT …/dpia incluye un
bloque screening. Marca los disparadores del Art. 35(3) de forma determinista:
automated_decision_making: true → toma de decisiones automatizada con
efectos legales o de significación similar (Art. 35(3)(a)).systematic_monitoring: true → monitorización sistemática de una zona
públicamente accesible (Art. 35(3)(c)).- Un
special_categories no vacío junto con large_scale: true →
tratamiento a gran escala de categorías especiales (Art. 35(3)(b)).
- Una sola marca de categoría especial o gran escala aún aparece como
indicador de alto riesgo (Art. 9 / Art. 35(1)).
screening.required: true significa que debe registrarse una DPIA antes de que la
actividad pueda pasar a active.
Ciclo de vida de estado
Una actividad atraviesa:
draft → active → under_review → retired
PATCH /compliance/processing-activities/{id} actualiza campos mutables
y/o avanza el estado:
Activar una actividad cuyo filtrado marca un requisito de DPIA se
rechaza con un 409 Conflict hasta que se haya registrado una DPIA cuyo resultado
no sea do_not_proceed. Esto es lo que hace el registro proactivo —
el tratamiento de alto riesgo no puede activarse sin documentación.
Leer el registro
GET /compliance/processing-activities — el registro completo más un
resumen: recuentos por estado, cuántas actividades el filtrado marca como
DPIA-requeridas (dpiaRequired), cuántas de esas aún no tienen DPIA registrada
(dpiaMissing), y cuántas DPIA registradas aterrizaron en un riesgo residual alto
(highResidualRisk).GET /compliance/processing-activities/{id} — una actividad con su
filtrado y, una vez registrada, su DPIA.
Registrar una DPIA
PUT /compliance/processing-activities/{id}/dpia — requiere una clave API de
administrador u owner. Registra (o reemplaza) la evaluación del Art. 35 para la
actividad.
consult_authority se corresponde con el deber de consulta previa del Art. 36 que se debe cuando un
riesgo residual alto no puede mitigarse. Un resultado de do_not_proceed
bloquea la activación de la actividad — déjelo solo cuando la evaluación
concluye que el tratamiento no puede continuar legalmente.
Cada DPIA registra quién la evaluó y cuándo (assessedAt, assessedBy).
Exportar el inventario del Art. 30
GET /compliance/processing-activities/inventory devuelve todo el
registro serializado a la forma lista para auditoría — el adjunto que un DPO entrega
a una autoridad de supervisión ante una solicitud del Art. 30(4), o adjunta a una
solicitud de evidencia de un auditor.
Cada registro lleva su estado de DPIA — dpiaRequired, dpiaRecorded,
dpiaOutcome, residualRisk — por lo que el inventario dobla como evidencia de que
el tratamiento de alto riesgo fue filtrado y evaluado.
Control de acceso
Las lecturas (GET) están disponibles para cualquier miembro autenticado de su
organización. Las escrituras (POST, PATCH, PUT …/dpia) están restringidas a
los roles de owner y admin — el registro es un control regulatorio, en
línea con el resto de la superficie de escritura de cumplimiento (incidentes de brecha,
política de retención). Cada presentación, actualización y registro de DPIA se escribe en
su log de auditoría con el actor, la referencia de la actividad y el resultado.
Referencias relacionadas
