本文へ移動
cccskills
無料GitHub で公開

data-portability

Executes GDPR Article 20 data portability requests, covering machine-readable format requirements (JSON, CSV, XML), direct controller-to-controller transfer mechanisms, and scope limitations to data provided by the subject on consent or contract basis. Activate for portability, data export, Art. 20, data transfer queries.

インストール方法を見る

含まれるファイル(5)

  • SKILL.md7.9 KB
  • assets/template.md3.9 KB
  • references/standards.md2.2 KB
  • references/workflows.md4.4 KB
  • scripts/process.py11.7 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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.
  2. Art. 20(2) — The data subject has the right to have the personal data transmitted directly from one controller to another, where technically feasible.

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

  4. 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.
  4. 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)
  2. Apply the scope filter from Step 2.
  3. De-duplicate records across systems.
  4. Validate data integrity (checksums, record counts).

Step 4: Format the Data

Meridian Analytics Ltd supports the following machine-readable formats:

FormatMIME TypeUse CaseSchema
JSONapplication/jsonDefault — structured, widely supportedSchema documented in API specification
CSVtext/csvTabular data, spreadsheet-compatibleHeader row with field names, UTF-8 encoding, RFC 4180 compliant
XMLapplication/xmlEnterprise integration, legacy systemsXSD schema provided with export

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.
  3. Obtain transfer confirmation (HTTP 200/201 response, SFTP receipt confirmation, or download confirmation).
  4. 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
  3. 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)
  2. Retain the processing record for 3 years.
  3. 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).

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Implements 42 CFR Part 2 protections for substance use disorder patient records. Covers written consent requirements stricter than HIPAA, re-disclosure prohibition, court order procedures, qualified service organization agreements, and 2024 amendments aligning Part 2 with HIPAA. Keywords: 42 CFR Part 2, substance use disorder, SUD records, re-disclosure, consent, Part 2 amendments.

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Privacy-Data-Protection-Skills3032026年3月17日 更新

Guides assessment of third-country adequacy decisions under GDPR Article 45 for international data transfers. Covers the current EC adequacy decisions list, adequacy assessment criteria, partial adequacy handling, and monitoring of adequacy decision reviews. Keywords: adequacy decision, Article 45, third country, adequate protection, EC adequacy list.

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Privacy-Data-Protection-Skills3032026年3月17日 更新

Implements age-gating mechanisms for online services to restrict access based on user age. Covers hard gates versus soft gates, neutral age prompts, re-verification triggers, circumvention prevention, and regulatory requirements under GDPR, COPPA, UK Online Safety Act, and DSA. Keywords: age gate, age restriction, neutral prompt, children, online services, access control.

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Privacy-Data-Protection-Skills3032026年3月17日 更新

Evaluates and implements age estimation and verification technologies for online services. Covers facial age estimation, digital ID verification, self-declaration with risk assessment, AI-based age estimation, and the accuracy versus privacy tradeoff. Includes ICO guidance and euCONSENT framework. Keywords: age verification, age estimation, facial analysis, digital ID, children, online safety.

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Privacy-Data-Protection-Skills3032026年3月17日 更新

Preparing EU AI Act compliance documentation for high-risk AI systems. Covers Annex III classification, technical documentation under Art. 11, conformity assessment, risk management systems, and CE marking requirements. Keywords: EU AI Act, high-risk AI, Annex III, conformity assessment, CE marking.

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Privacy-Data-Protection-Skills3032026年3月17日 更新

Implements GDPR Art. 22 automated decision-making and AI Act Art. 14 human oversight requirements for AI systems. Covers identification of solely automated decisions, meaningful human intervention design, logic explanation mechanisms, and contestation procedures. Keywords: Art. 22, automated decision, human oversight, AI Act, profiling, contestation.

日本語の概要は準備中です。原文の説明を表示しています。

mukul975/Privacy-Data-Protection-Skills3032026年3月17日 更新

mukul975 のスキルをすべて見る

このスキルの問題を報告する