data-portability

Executing Data Portability Requests

Overview

The right to data portability under GDPR Article 20 allows data subjects to receive their personal data in a structured, commonly used, and machine-readable format, and to transmit that data to another controller without hindrance. This skill provides the complete workflow for assessing scope, extracting data, formatting output, and facilitating direct transfers.

Legal Foundation

GDPR Article 20 — Right to Data Portability

1. Art. 20(1) — The data subject has the right to receive the personal data concerning them, which they have provided to a controller, in a structured, commonly used and machine-readable format, and has the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided, where:

• (a) the processing is based on consent under Art. 6(1)(a) or Art. 9(2)(a), or on a contract under Art. 6(1)(b); AND
• (b) the processing is carried out by automated means.

1. Art. 20(2) — The data subject has the right to have the personal data transmitted directly from one controller to another, where technically feasible.

1. Art. 20(3) — The exercise of portability shall not adversely affect the rights and freedoms of others.

1. Art. 20(4) — The right to portability shall not apply to processing necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller.

Scope: What Data Is Portable

Per EDPB (formerly WP29) Guidelines on the right to data portability (WP242 rev.01), portable data includes:

1. Data provided by the data subject: Information actively and knowingly provided (e.g., account details, form submissions, uploaded content).
2. Observed data: Data generated by the data subject's activity (e.g., search history, location data, activity logs, raw sensor data from connected devices).
3. NOT included — Inferred or derived data: Data created by the controller through analysis (e.g., credit scores, profiling segments, algorithmic assessments). These are the controller's intellectual output.

Legal Basis Filter

Portability applies ONLY where the legal basis for processing is:

• Art. 6(1)(a) — Consent
• Art. 9(2)(a) — Explicit consent (for special category data)
• Art. 6(1)(b) — Performance of a contract

Portability does NOT apply to data processed under:

• Art. 6(1)(c) — Legal obligation
• Art. 6(1)(d) — Vital interests
• Art. 6(1)(e) — Public interest / official authority
• Art. 6(1)(f) — Legitimate interests

Portability Request Workflow

Step 1: Receive and Validate the Request

1. Log the request with reference PORT-YYYY-NNNN.
2. Verify the requester's identity (tiered verification as per DSAR process).
3. Determine whether the request is for:

• (a) Self-export: Data subject wants to receive their data directly.
• (b) Direct transfer: Data subject wants data transmitted to another controller.

1. If direct transfer, obtain the receiving controller's details:

• Organisation name and registered address
• Technical contact email
• API endpoint or secure transfer mechanism (if available)
• Data format preference

Step 2: Scope Assessment

1. Identify all personal data the subject has provided or that has been observed through their use of the service.
2. Filter by legal basis — include only data processed under consent (Art. 6(1)(a)/Art. 9(2)(a)) or contract (Art. 6(1)(b)).
3. Exclude inferred or derived data (profiling scores, analytics outputs, internal assessments).
4. Exclude data that would adversely affect the rights and freedoms of others (Art. 20(3)) — redact third-party personal data from exported datasets.
5. Confirm that processing is carried out by automated means (manual paper files are excluded).

Step 3: Data Extraction

1. Query all relevant systems for the in-scope data:

• Customer account database
• Transaction/order history
• User-generated content (uploads, posts, messages authored by the subject)
• Service interaction logs (observed data)
• Preference and settings data
• Connected device data (if applicable)

1. Apply the scope filter from Step 2.
2. De-duplicate records across systems.
3. Validate data integrity (checksums, record counts).

Step 4: Format the Data

Meridian Analytics Ltd supports the following machine-readable formats:

Format selection priority:

1. If the data subject specified a preferred format, use it (if supported).
2. If the receiving controller specified a format, use it.
3. Default to JSON.

Data packaging:

• Each data category is exported as a separate file (e.g., account_data.json, transactions.csv, content_uploads.json).
• A manifest file (manifest.json) lists all included files, record counts, date ranges, and checksums.
• Files are packaged into a single ZIP archive with AES-256 encryption.

Step 5: Execute Direct Transfer (If Applicable)

If the data subject requested direct controller-to-controller transfer under Art. 20(2):

1. Verify the receiving controller's identity and authorisation.
2. Establish a secure transfer channel:

• Option A — API transfer: If the receiving controller provides an API endpoint, transmit via HTTPS with mutual TLS authentication.
• Option B — SFTP transfer: Establish an SFTP connection with SSH key authentication.
• Option C — Secure file exchange: Upload the encrypted archive to a secure portal and provide time-limited access credentials to the receiving controller.

1. Obtain transfer confirmation (HTTP 200/201 response, SFTP receipt confirmation, or download confirmation).
2. If direct transfer is not technically feasible, notify the data subject and provide the data directly to them instead, per Art. 20(2).

Step 6: Deliver to Data Subject (Self-Export)

1. Upload the encrypted archive to the secure download portal.
2. Send notification to the data subject with:

• Secure download link (72-hour expiry)
• Decryption password (sent via separate channel — SMS or secondary email)
• Manifest summary (file list, record counts)
• Instructions for opening the archive

1. Record the delivery confirmation.

Step 7: Close and Document

1. Update the portability request register with:

• Completion date
• Data categories exported
• Format used
• Transfer method (self-export or direct transfer)
• Recipient controller (if direct transfer)

1. Retain the processing record for 3 years.
2. The export does NOT require deletion of the original data — portability is an additional right, not a replacement for erasure.

Response Timeline

• Standard deadline: 30 calendar days from receipt of the request.
• Extension: Up to 60 additional days for complex requests (Art. 12(3)).
• No fee: The first copy must be provided free of charge. Additional copies may incur a reasonable fee under Art. 12(5).