The customer data portability decision record: why the export scope you configured determines your GDPR compliance evidence gap and your right-to-erasure verification failure mode

A 28-person SaaS company that built project management tooling for creative agencies had run a GDPR compliance sprint in its twenty-second month, three weeks before its first enterprise customer's security review was scheduled. The sprint had been triggered by the customer's vendor questionnaire, which included a section on data subject rights. The engineering manager and the company's outside counsel had worked through the questionnaire together; the answers that required engineering work had been translated into a sprint backlog of five items: add a data export button to account settings, add a delete account button to account settings, update the privacy policy with the required GDPR language, add a cookie consent banner, and add a data processing addendum template to the legal page.

The data export button generated a zip file containing three CSVs: user profile data, project records belonging to the account, and asset metadata for files uploaded by the account. The engineering manager had asked the two engineers assigned to the feature which tables contained user data; they had identified the three primary tables in the application database and built the export from those. The export had gone into production three days before the enterprise customer review. The review had passed. The questionnaire had been archived in the company's compliance folder.

Over the following twenty-two months, the product grew significantly. The company had added a real-time collaboration feature that generated event streams ingested into a Snowflake data warehouse for usage analytics. It had integrated Segment for product analytics and Datadog for application performance monitoring and error tracking. It had added an Algolia search index populated with project titles, asset names, and user-created tags to support the product's search feature. It had onboarded a customer success platform that ingested user activity data to track engagement scores and trigger automated in-app messages. None of these systems had been added to the data export scope when they were integrated. The engineering team that had built the original export had turned over significantly; the two engineers who had identified the three primary tables were no longer at the company.

In the company's forty-fourth month, a user submitted a formal Data Subject Access Request through the privacy email address listed in the privacy policy. The user was a freelance designer who had used the platform for eighteen months as part of a larger agency team, had left the agency, and wanted a complete record of all personal data the company held about them before closing their account. The company's operations manager, who was the de facto privacy contact, forwarded the email to the engineering manager and asked how long the export would take to produce. The engineering manager pulled the existing export for the user's account and sent it within the standard 30-day window.

The user responded nine days after receiving the export. They had used a browser extension that listed all services they had authenticated with, and they had noted that the company's platform appeared in Datadog's Known Services list through a shared workspace they had briefly had access to through the agency. They asked whether the export included their activity data from the analytics system. The operations manager escalated to the engineering manager. The engineering manager investigated and discovered that the Snowflake warehouse contained three years of behavioral event data for every user — click events, session durations, feature usage sequences, device and browser fingerprints, and IP addresses. None of it was in the export. The Segment analytics database contained similar behavioral data. The Algolia search index contained indexed versions of project titles and tag strings that could be traced to individual users. The customer success platform contained engagement scores, predicted churn probabilities, and automated message delivery records — all keyed to user email addresses.

The engineering team spent six weeks building export coverage for all four additional systems. During those six weeks, three additional DSARs arrived from other users. Two received the incomplete primary-database export because the remediation was not complete. The company's legal counsel advised that incomplete DSAR responses during a known gap-remediation period were a compliance risk that should be documented. The documentation was added to the compliance folder. The six-week remediation had required two full-time engineers because the Snowflake export required building a data transformation pipeline from the raw event stream schema to a human-readable format, and the customer success platform's data export API had not been used before and required debugging against a rate-limited sandbox. The cost of the remediation was measurably larger than the cost of including the four systems in the original export scope would have been — the original sprint had missed them not because they were hard to include but because the engineers assigned to the sprint had been asked which tables in the primary database contained user data, not which systems across the entire infrastructure stack held personal data.

A 33-person B2B SaaS platform that built sales enablement tooling for enterprise revenue teams had implemented its right-to-erasure flow during a legal review triggered by a large customer's Data Processing Agreement negotiation. The DPA required the company to be able to demonstrate erasure of personal data within 30 days of a verified request. The engineering team had built a delete account flow that executed four operations: a cascading delete from the primary PostgreSQL database (user record, activity records, and all content rows referencing the user's ID), an unsubscribe call to the Mailchimp email marketing platform, a customer deletion call to the Stripe API, and an anonymization update to the Intercom contact record (replacing the name and email fields with anonymized placeholders rather than deleting, because deleting the Intercom record would have broken the company's support ticket history for that customer). The flow had been reviewed by the legal counsel and the DPA had been signed.

The deletion flow covered every system the engineering team had been aware of when it was built. The team had not produced a personal data inventory before building the flow — the four systems had been identified by asking the same two engineers who had built the original waitlist and onboarding flows which systems held user data. The erasure design did not specify a protocol for updating the deletion flow when a new system was added. It did not specify what to do about PostgreSQL backup snapshots, which were retained for 90 days via automated pg_dump to an S3 bucket. It did not specify a verification protocol — a set of checks run after the deletion operations that confirmed each operation had succeeded. It did not produce a deletion evidence record that could be shown to a regulator.

Over the following eighteen months, the company had added a Mixpanel analytics integration for product analytics, a Sentry integration for error tracking, a Salesforce integration that synced contact and activity data for enterprise accounts, and an AWS OpenSearch cluster that indexed user-generated content for the product's search feature. Each integration had been added by a different engineer working on a different feature sprint. None had been cross-referenced with the erasure flow. The Mixpanel integration sent user email addresses as distinct IDs. Sentry's default configuration captured the authenticated user's email address and user ID in the error event context, attaching them to every stack trace. The Salesforce sync wrote contact records keyed to user email addresses. The OpenSearch index contained indexed versions of user-generated content with user ID metadata.

Eighteen months after the DPA had been signed, the company underwent a data protection audit conducted by its largest customer, a publicly-traded enterprise with its own DPO. The audit included a verification test: the auditor submitted a deletion request for a test account, observed the deletion flow in real time, and then checked each known system for residual data. The auditor found personal data in four places: the Mixpanel analytics database, which had not received a deletion call because it was not in the deletion flow; Sentry error events from the past 90 days, which contained the test user's email address in the error context; the Salesforce contact record, which had not been deleted because the Salesforce sync was write-only — the deletion flow had no Salesforce deletion step; and the S3 backup bucket, where the previous night's pg_dump contained the test user's record because the deletion had occurred after the nightly backup window.

The auditor then asked for erasure evidence for the 340 historical deletion requests the company had processed since the DPA was signed. The company produced its deletion confirmation emails to users, each of which stated "your account and associated data have been deleted." The auditor asked for system-level evidence: confirmation logs from each system, timestamps of each deletion, and confirmation that backup data had been overwritten. No such evidence existed. The deletion flow had logged its own execution in the application log, but the application log was rotated at 30 days and 38 weeks of logs were gone. The company could demonstrate that the deletion button existed. It could not demonstrate that deletion had been complete, that it had covered the correct systems, or that backup data had been handled.

The remediation required eleven weeks: three weeks to build a deletion evidence logging system that captured per-system deletion confirmation and stored it in a compliance audit log with a 7-year retention policy, four weeks to build deletion integrations for Mixpanel, Sentry data retention policies, Salesforce, and OpenSearch, two weeks to build a backup data documentation process that recorded each S3 backup generation timestamp, its expected overwrite date, and the deletion requests that were pending backup overwrite at any given time, and two weeks to run a retroactive analysis of historical deletion requests against available system logs to produce the best-available evidence record for the 340 prior requests. The retroactive analysis was materially incomplete because the application logs had been rotated. Legal counsel prepared a disclosure to the enterprise customer explaining the gap and the remediation.

A 41-person SaaS company that built contract lifecycle management tooling for in-house legal teams had implemented data portability as part of a GDPR compliance update in its third year. The product stored significant personal data — counterparty contact records, negotiation history, signature metadata, and obligation tracking records — and the DPO had flagged that GDPR Article 20's portability right was particularly material for contract management software because a customer terminating the SaaS contract would have a strong legitimate interest in retrieving their contract data in a format that could be imported into a competing service.

The engineering team had built the portability export as a zip file containing seven CSV files, one per database table with personal data content: contacts, contracts, contract versions, obligations, signatures, audit events, and counterparty organizations. Each CSV was exported directly from the corresponding database table with all columns included. The export was generated on demand from the account settings page and was available for 24 hours via a signed download URL. The implementation had taken four days, had been reviewed by the DPO, and had been marked as satisfying the Article 20 requirement in the compliance documentation.

The export design did not include a manifest file describing the contents of the zip. It did not include schema documentation for any of the seven CSVs — the column names were the raw database column names, which used an internal naming convention developed over three years of migrations and included names such as `clt_v2_contact_ext_ref`, `sig_party_a_ts_utc`, and `obl_recur_cadence_cd`. The foreign key relationships between tables used internal integer IDs that had no meaning outside the originating database. A row in the contracts CSV referenced a contact via a `primary_contact_id` integer; a row in the obligations CSV referenced a contract via a `parent_contract_uuid` field that was a UUID in the obligations table but was stored as an integer in the contracts table because the contracts table had been created before the company had standardized on UUIDs. The inconsistency was a known technical debt item in the engineering backlog.

Two years after the portability export was implemented, the company lost a competitive renewal with a 200-person legal team at a manufacturing company. The legal team had decided to migrate to a competing CLM product. The DPO at the manufacturing company formally invoked GDPR Article 20 portability rights, requesting that the data be provided in a format that the new vendor could import. The company generated the portability export and delivered it within the 30-day window.

The receiving vendor's implementation team attempted to import the export. They could not parse the column names without manual intervention on all seven files. They could not reconstruct the relational structure between contacts, contracts, and obligations because the foreign key inconsistency between the `primary_contact_id` integer and the `parent_contract_uuid` UUID meant that joining the tables required a mapping step that was not documented anywhere in the export. They could not identify which fields constituted personally identifiable information and which were internal metadata because there was no schema documentation. After four hours of effort, the receiving vendor's implementation lead told the manufacturing company's legal team that the import would require a custom transformation project estimated at 40 hours of professional services time.

The manufacturing company's legal team escalated to their national DPA. The formal complaint characterized the export as technically satisfying the CSV format requirement while failing the "structured, commonly used format" and "technically feasible direct transmission" standards of Article 20 — an export that required 40 hours of professional services to interpret was not, in the legal team's view, a format that the regulation had intended to create. The DPA opened a preliminary inquiry. The company's legal counsel spent three months responding to the inquiry, ultimately resolving it with a commitment to implement a documented schema and a manifest file within 90 days. The 90-day remediation had required one full-time engineer, one technical writer, and four rounds of review by the DPO and legal counsel.

The remediation was straightforward: a manifest file in JSON format listing each file, its contents, and its record count; a schema documentation file in JSON Schema format with human-readable field descriptions for every column in every CSV; a cross-reference section in the schema documentation explaining each foreign key relationship and how to join tables; and a field classification that labeled each column as either personal data, organizational data, system metadata, or internal identifier. The work had taken six weeks. The original export implementation had taken four days because it had been scoped as a technical implementation rather than as a portability service — the question the founding engineers had answered was "how do we export the data?" not "how does a receiving system import this data?"

Structural properties set by the customer data portability decision

Three structural properties are determined when a founding team configures its data portability and right-to-erasure implementation: how complete the DSAR export is relative to the actual personal data footprint, how verifiable the erasure is across distributed systems including backup data, and how genuinely interoperable the portability format is versus technically compliant but practically unusable. None are labeled explicitly in the founding compliance implementation — they are properties that emerge from the assumptions the founding engineers embed about which systems hold personal data, what deletion means across a distributed stack, and what "machine-readable format" means in a context where a data subject might actually attempt to use the output.

Property 1: The export scope and the compliance evidence gap. Data portability and DSAR export implementations are scoped against the personal data inventory the engineering team can construct informally at the time of the compliance sprint — typically the primary application database and the third-party integrations that are operationally visible to the engineers assigned to the sprint. As the product grows, personal data accumulates in secondary systems: analytics warehouses receive behavioral event streams, error tracking platforms capture user context in stack traces, search indexes ingest user-generated content, customer data platforms receive enriched contact records, and data enrichment services add derived attributes keyed to user email addresses. Each of these integrations is added by engineers working on feature sprints who are not thinking about the DSAR export — they are thinking about the feature the integration enables. The founding DSAR export, which was designed against a snapshot of the data footprint, covers a shrinking fraction of actual personal data as the integration count grows. The fraction is invisible because there is no mechanism that triggers an export scope review when a new integration is added. The founding compliance documentation records the export feature as complete; the actual completeness declines quarter by quarter. The structural fix is to maintain a personal data inventory that is updated as a required step in the integration deployment process — before a new third-party integration goes to production, a data classification review documents what personal data the integration receives, how it stores that data, how long it retains it, and what API or mechanism exists for deletion and export; the DSAR export scope is updated to include the new system before the integration goes live, not as a deferred backlog item. The multi-tenant data isolation decision record connects at the data scope layer: the tenant boundaries that determine which data a customer can access through the product also determine the scope of data that belongs to a customer under GDPR Article 20 portability; the portability export scope and the tenant isolation model must be reviewed together when either changes, because a portability export that leaks cross-tenant data through an insufficiently scoped query creates both a GDPR violation and a data isolation failure simultaneously. The compliance automation decision record connects at the process layer: automated DSAR intake, assignment, and status tracking reduces the operational overhead of responding to data subject requests but does not itself solve the export scope problem; automation that routes a DSAR to the engineering team and tracks the 30-day response window is more valuable than automation that auto-generates an incomplete export, because a documented manual step with a clear owner produces a better outcome than an automated step that produces a non-compliant artifact.

Property 2: The deletion verification model and the right-to-erasure failure mode. Erasure implementations are designed as a database delete plus a set of API calls to the third-party integrations the engineering team can enumerate during the implementation sprint. The design is typically not accompanied by a personal data inventory, a verification protocol, or a backup data handling specification — those artifacts require effort beyond the implementation itself and are rarely included in a sprint that has been time-boxed to satisfy a customer DPA deadline. The deletion flow that covers all known systems at founding covers a shrinking fraction of actual personal data stores as the integration footprint grows, for the same reason the DSAR export scope does: new integrations are added by engineers working on features, not on compliance, and the erasure flow update is a deferred item that may never be scheduled. The backup data dimension compounds the failure: backup snapshots are personal data under GDPR and must be within the erasure scope, either by being deleted explicitly or by a documented schedule that specifies when each backup generation will overwrite the deleted data; most erasure implementations treat backup data as out of scope and leave the gap undocumented; a DPA audit that tests the erasure claim by inspecting backup data surfaces the gap under conditions that do not allow the six-month remediation timeline that a proactive backup data policy would have produced. The verification protocol dimension is the most operationally consequential: an erasure flow that executes correctly produces no visible output by design — the absence of data is the expected outcome — and without a confirmation log that records the timestamp, the systems covered, and the confirmation signal from each system, the erasure cannot be demonstrated to a regulator; the company can show that the delete button exists; it cannot show that the delete operation completed, that it covered all required systems, or that backup data is within the overwrite schedule. The structural fix is a deletion evidence log: a dedicated compliance store, not subject to the erasure request itself, that records a structured event for each deletion operation — the request ID, the data subject identifier, the system, the operation timestamp, the success signal, and for backup stores the expected overwrite date — retained for the regulatory demonstration period. The database backup verification decision record is directly relevant: the backup verification process that confirms restore completeness must also specify the backup retention window as a personal data retention constraint; when the backup retention window is specified only as an operational parameter (retain for 90 days for disaster recovery purposes) without a GDPR dimension (backup data is personal data that must be included in the erasure scope or subject to a documented overwrite schedule), the two decisions produce a gap that surfaces only under regulatory scrutiny. The audit log decision record connects at the retention conflict layer: audit logs often contain personal data in the event context — the user ID who performed an action, the email address of the affected record, the IP address of the request origin — and the right to erasure creates a tension with audit log retention requirements that is easiest to manage by separating personal identity from audit event content at the time the audit logging decision is made, not retroactively after the tension surfaces in a deletion request.

Property 3: The portability format design and the interoperability surface. GDPR Article 20 requires portable data to be in a structured, commonly used, machine-readable format — and where technically feasible, to be transmittable directly to another controller. The founding portability implementation that generates CSV or JSON exports from database tables satisfies the format requirement in a narrow technical sense but fails the interoperability interpretation in practice when: the column names are internal identifiers derived from a migration history rather than human-readable field names; the foreign key relationships between tables use inconsistent identifier types that require knowledge of the database schema to join; no manifest file describes what is included in the export; no schema documentation explains what each field means; and no test has been run to determine whether a receiving system can consume the export. The portability feature that exists for regulatory compliance purposes and the portability feature that enables genuine data mobility are different engineering artifacts, and the founding decision that scopes portability as a compliance checkbox produces the former. The gap between technical compliance and genuine interoperability is invisible until tested — and it is typically tested first by a customer who wants to leave, which means the gap is discovered under conditions where the company's relationship with the customer is already adversarial, the customer has regulatory rights as leverage, and the remediation timeline is measured in weeks rather than months. The structural fix is to test the portability claim before it is claimed: identify the most plausible receiving system or open standard for the product category (a competing product, an industry-standard import format, a widely-used interchange standard), run the portability export through an import test against that system, and document the result; if the import test fails, the portability feature is not complete regardless of its regulatory status in the compliance documentation. The API security decision record connects at the access control layer: the portability export endpoint must enforce the same identity verification that the DSAR process requires — a portability request from an authenticated account produces an export of that account's data; the authorization model must confirm that a portability request cannot be used to export another account's data, and the export endpoint must enforce per-account scoping with the same rigor as any other data access boundary in the product. The access control model decision record connects at the privilege layer: in multi-user organizations, portability rights belong to the individual data subject, not the organization account; an individual user's right to their personal data is distinct from the organization's right to the business data the individual created while using the product; the portability export design must specify which data categories are portable by the individual user and which are accessible only to the organization account, and this distinction must be consistent with the product's underlying access control model and the DPA terms agreed with business customers.

What the founding session records and what it omits

The founding session that establishes data portability and right-to-erasure compliance — typically a sprint triggered by a customer security review, a DPA negotiation, or an approaching regulatory enforcement date — records the implementation: the export button, the delete account flow, the API calls to known third-party systems, the privacy policy update. If the team has engaged outside counsel, it records the legal review and the DPA template. If the team has thought carefully about the user experience, it records the download format and the 24-hour link expiry. What it does not record is the personal data inventory the implementation was scoped against, the fraction of actual personal data the export covers, the systems explicitly excluded from the deletion flow and why, the backup data retention schedule and its relationship to the erasure window, or the portability format test that would confirm the export is genuinely interoperable rather than technically compliant.

These omissions are structurally similar across the decision record series: they are benign at founding, when the omissions are covered by the founding team's shared context and by the product's small data footprint. The export scope omission is not a risk at founding when the product has one database and two third-party integrations and the engineering team can enumerate all personal data stores in a meeting. The deletion verification omission is not a risk at founding when the deletion flow covers all systems, the backup retention window is short, and no regulatory audit has been announced. The portability format omission is not a risk at founding when no customer has actually attempted to use the portability export to migrate to a competing service.

The failure modes develop along three distinct timelines. The export scope failure develops from integration accumulation — a continuous process that adds one new personal data store at a time, each addition benign in isolation, until the cumulative gap between the export scope and the actual data footprint is large enough to be visible in a formal DSAR response. The deletion verification failure develops from a combination of integration accumulation and the absence of a verification protocol — the deletion flow gaps accumulate the same way the export scope gaps do, but the verification absence means the gaps are invisible even to the team running the deletion flow until a regulator tests the claim. The portability format failure develops from the gap between a compliance framing of portability (the feature that satisfies the regulation) and a service framing (the feature that enables a data subject to actually use their data) — a gap that is invisible until a motivated data subject or a DPA auditor tests the portability claim empirically rather than accepting the compliance documentation at face value.

The customer data portability ADR closes these gaps by producing a personal data inventory at founding, specifying the export scope as a fraction of identified personal data stores rather than as a list of implemented features, establishing a deletion evidence protocol that generates a compliance-demonstrable record for every erasure request, and including a portability format test in the definition of done for the portability feature. The decisions never written down in the data portability domain are not the implementation decisions — the export button exists, the delete flow runs, the CSV is generated. They are the inventory of which systems hold personal data and what fraction of it the export covers, the protocol for demonstrating that deletion was complete across all systems including backup data, and the test that the portability format enables genuine data mobility rather than regulatory compliance theater. The new CTO onboarding problem in the data portability domain is specific: the incoming technical leader finds the export feature and the delete account flow in the product, finds the DPA template and the compliance documentation in the legal folder, but cannot determine which systems are in scope, what fraction of personal data the export covers, how deletion completeness is verified, how backup data is handled, or whether the portability export has ever been tested against a receiving system. The customer data portability ADR makes those decisions explicit, verifiable against the current integration footprint, and auditable against the deletion evidence log. The encryption-at-rest decision record connects at the export packaging layer: portability exports contain personal data in transit from the company's systems to the data subject; the export package must be encrypted in transit (HTTPS download) and the download link must expire after a short window; if the export is large enough to be sent via email attachment, the packaging decision must specify whether the attachment is encrypted and what key-sharing mechanism is used, because an unencrypted email attachment containing a GDPR data export is a personal data transmission to a system not under the company's control and constitutes a separate compliance risk from the export completeness question. The WhyChose extractor finds the data portability discussions in your AI session history — the conversation where the DPO walked through the Article 20 requirements, where the engineering manager decided which systems to include in the export sprint, where the team debated what "machine-readable format" meant in practice, or where someone asked whether backup data was in scope for the erasure flow and the answer was deferred to a later session — and surfaces those parameters so you can assess which assumptions still hold against the current integration footprint, backup retention schedule, and regulatory environment.

The customer data portability ADR: five sections

Section 1: Personal data inventory and export scope definition. Specify the personal data inventory at the time of the decision: the complete list of systems that hold personal data, the data categories each system holds, the retention period in each system, and the mechanism by which the inventory is updated when a new system is added to the product stack. Express the DSAR export scope as a fraction: the number of identified personal data stores included in the export divided by the total number of identified personal data stores, stated as a percentage with the excluded systems and their exclusion rationale listed explicitly. A system excluded because its data is not subject to portability rights (for example, an internal analytics system used only for aggregate analysis that contains no personal identifiers) must be excluded with a documented legal basis, not merely omitted. A system excluded because the export integration has not been built yet must be listed as a known gap with a scheduled remediation date, not omitted from the inventory. Specify the inventory update process: a required step in the engineering deployment process for new third-party integrations, executed before the integration goes to production, that classifies the integration's personal data receiving and retention behavior and updates both the personal data inventory and the DSAR export scope. Connect this section to the multi-tenant data isolation decision record: the export scope must be consistent with the tenant isolation model — a DSAR export query that uses an insufficiently scoped data access path can traverse tenant boundaries and include data belonging to other users or organizations; the export query scope must be reviewed against the tenant isolation model before deployment and must be included in the isolation model's security review cadence.

Section 2: Erasure protocol, verification design, and backup data handling. Specify the erasure protocol as an ordered list of operations: each system, the operation used to delete personal data in that system, the API endpoint or query, the expected response that confirms deletion, and the fallback for a failed deletion operation. Specify the verification protocol: the set of checks run after the erasure operations that confirm deletion has completed in each system — not a declarative confirmation but a verification query that confirms absence; for database systems, a SELECT that returns zero rows; for third-party API systems, a GET that returns a 404 or a not-found status. Specify the deletion evidence log: a compliance-specific store, not subject to the deletion request itself, that records a structured event for every erasure operation — the request ID, the data subject identifier, the system name, the operation timestamp, the confirmation signal, and the operator identity if manual verification was required. Specify the backup data retention schedule: for every backup system in scope, the backup generation cadence, the retention window, and the expected date on which a deletion that has completed in the primary system will be overwritten in all backup generations; include this schedule in the DSAR response to the data subject so the erasure timeline is transparent rather than implied by a confirmation email that suggests immediate completeness. Connect this section to the database backup verification decision record: the backup verification procedure must specify backup data as a personal data store under GDPR, must include the backup retention window in the personal data inventory, and must define the backup overwrite event as a scheduled personal data deletion event that is tracked in the deletion evidence log alongside the primary system deletion. Connect this section to the audit log decision record: where audit logs contain personal data in the event context, the erasure protocol must specify the handling — anonymization if the legal basis for retention overrides the erasure right, deletion if not — and the legal basis for any retention exception must be documented in the erasure protocol, not assumed from the audit logging configuration.

Section 3: Portability format specification and interoperability test. Specify the portability output format: the container format (zip, tar, single file), the data format for each category (JSON, CSV, XML), the encoding, and the download mechanism. Specify the schema documentation: a machine-readable schema description (JSON Schema or equivalent) for every data category in the export, with human-readable field names and descriptions for every field, explicit identification of fields that are personal data versus organizational data versus system metadata, and a cross-reference section for every foreign key relationship — including the identifier type used in each table and a join example. Specify the manifest file: a structured file included in every export that lists each component file, its data category, its record count, the date range of the data, and the system from which it was exported; the manifest allows a receiving system to validate export completeness before attempting import. Specify the portability format test: the receiving system or standard against which the export is tested, the import test procedure, and the test result — the portability feature is not complete in the decision record until a test import has been run and documented. Specify the test cadence: the portability format test is run at minimum annually and after any schema change to any personal data store in scope, because schema changes in the source systems produce column name changes, type changes, or relationship changes in the export that break a previously-passing import test. Connect this section to the API security decision record: the portability export endpoint must enforce account-scoped data access with the same authorization rigor as any data access boundary in the product; the endpoint must verify that the requesting identity is the data subject whose data is being exported, not merely an authenticated user in the same organization; a portability export that returns organizational data for any authenticated account rather than personal data for the requesting individual is a data access control failure that the portability feature introduces if the authorization scope is not specified explicitly.

Section 4: DSAR response process, escalation protocol, and regulatory timeline compliance. Specify the DSAR intake and triage process: the email address or form that receives requests, the identity verification requirement (how the company confirms the requester is the data subject whose data they are requesting), the maximum response time (30 days under GDPR, with one 60-day extension available for complex requests), and the internal escalation path when a request cannot be fulfilled within the standard timeline. Specify the DSAR response content: the export link, the retention period for the download link, the backup data retention schedule, the systems included in the export and their data categories, and the contact for follow-up questions. Specify the complex request protocol: a DSAR that cannot be fulfilled within 30 days requires a written notice to the data subject within 30 days explaining the delay and the expected completion date; the condition for invoking the complex request extension must be documented — a new system integration gap, a data volume that requires extended processing, or a request scope that requires legal review — and must not be used as a routine extension mechanism. Specify the regulatory response escalation: if a DSAR is forwarded to a national DPA or if a DPA inquiry is opened, the response protocol transitions from the engineering and operations team to legal counsel within a defined escalation window; the escalation trigger, the documentation required, and the legal counsel contact must be specified in the decision record rather than improvised at the time of the regulatory contact. Connect this section to the compliance automation decision record: DSAR intake automation — form-based requests, automated identity verification, workflow routing, and timeline tracking — reduces the operational overhead of responding to requests and the risk of missing the 30-day window; the automation design must specify how the automated flow handles requests that require manual steps, such as new system export gaps or requests for data in systems without automated export APIs, so that automation does not produce a false completion signal for a request that is still open.

Section 5: Personal data inventory maintenance, integration review gate, and compliance review cadence. Specify the integration review gate: a structured review, executed before any new third-party integration goes to production, that classifies the integration's personal data receiving, storage, and retention behavior and updates the personal data inventory, the DSAR export scope, and the erasure protocol. The review must produce a written artifact that is stored in the compliance documentation folder, not merely discussed in a sprint review. Specify the personal data inventory maintenance cadence: a quarterly review of the inventory against the current integration list, the current data warehouse schema, and the current third-party service list, with any gaps between the inventory and the current state resulting in a scheduled remediation item. Specify the portability and erasure compliance review: an annual review that covers the export completeness fraction against the personal data inventory, the deletion evidence log completeness rate (the fraction of deletion requests for which a complete evidence record exists), the portability format test results, and the DSAR response time distribution against the regulatory deadline; the review must produce a written summary that can be shown to a DPA or included in a security questionnaire response. Specify the third-party integration deletion API test cadence: a quarterly automated test of each third-party integration's deletion API using a test record, confirming that the API call succeeds and the confirmation signal matches the expected format; API changes in third-party systems that break the deletion flow are invisible unless actively tested, because the deletion flow executes only when a deletion request arrives and a silent API failure produces a deletion that appears to have succeeded but has not. Connect this section to the access control model decision record: the portability and erasure rights belong to the individual data subject; the access control model that governs what a user can see and do within the product also governs whose data is included in a portability export and whose data is deleted in an erasure request; when the access control model changes — new roles, new organizational hierarchies, new team scoping — the portability and erasure scope must be reviewed for consistency, because access control changes that affect data visibility also affect the data subject rights scope in ways that may not be visible to the engineers implementing the access control change.

FAQ