Right to Portability

The core technical requirement of the right to portability is the format of the data export. Data must be provided in a format that is structured (organized in a predefined way), commonly used (not proprietary or obscure), and machine-readable (easily parsed by software).

• Recommended formats: JSON, CSV, XML, and Parquet for tabular data.
• Unacceptable formats: Scanned PDFs, image files of text, or proprietary binary blobs.
• Goal: Enable direct, automated ingestion by another data controller's systems without manual reformatting.

The right is not a blanket export of all data an organization holds. It applies specifically to personal data provided by the data subject to a controller, and processed by automated means based on consent or a contract.

• Included: Actively submitted data (e.g., name, email, uploaded photos) and passively observed data (e.g., raw search history, location logs, heart rate telemetry).
• Excluded: Inferred data and derived data created by the controller's proprietary algorithms (e.g., a user's credit score, a health risk profile, or a churn prediction).
• Legal Basis: Article 20 of the GDPR and Section 1798.100 of the CCPA/CPRA.

Where technically feasible, the data subject has the right to request the direct transmission of their personal data from one controller to another, bypassing the subject entirely. This creates a technical mandate for interoperability.

• Mechanism: Requires secure, authenticated APIs for controller-to-controller data transfer.
• Standardization: Industry efforts like the Data Transfer Project (DTP)—founded by Google, Meta, Microsoft, and Twitter—provide open-source frameworks for this direct transfer.
• Constraint: The sending controller is not obligated to adopt a specific technical system but must implement a reasonable, secure method for direct transfer when requested.

Fulfilling portability requests at scale demands a robust Privacy Request Orchestration layer and well-designed APIs. The export must be a complete, faithful representation of the data, not a summary.

• API Design: RESTful endpoints that authenticate the subject, query all relevant data stores (via Data Lineage for PII), and package the response in a standardized schema.
• Security: Strong identity verification is critical before executing a transfer to prevent unauthorized data exfiltration.
• Volume Handling: Systems must handle large exports (e.g., years of location history) without timing out, often using asynchronous jobs with a status-check endpoint.

Data portability is a distinct and supplementary right, not a replacement for the general Right of Access. They serve different purposes and have different technical requirements.

• Right of Access (Art. 15): Provides a human-readable copy of all personal data and metadata (purposes, recipients, retention periods). The goal is transparency.
• Right to Portability (Art. 20): Provides a machine-readable subset of data for reuse. The goal is interoperability and user control.
• Key Difference: An access request might yield a PDF report, which is insufficient for portability. A portability request must yield raw, structured data.

The right to portability is not absolute. It is constrained by the rights and freedoms of others, which creates complex technical challenges in multi-user datasets.

• Third-Party Data: Exports must not adversely affect the rights of other individuals. Data containing joint personal information (e.g., a messaging thread) requires technical filtering or consent from the third party before inclusion.
• Security Risk: Portability hubs become high-value targets for attackers. A compromised portability API can lead to mass data exfiltration.
• Trade Secrets: The right does not compel a controller to reveal proprietary algorithms or trade secrets, which is why inferred data is explicitly excluded from the scope.