A user-data export should begin with the request and legal right involved, not an automatic dump of the users table. Under EU GDPR, the right of access in Article 15 and the right to data portability in Article 20 overlap, but they cover different data and produce different outputs. A request that says “send me my data” may require clarification or a response covering both.
Article 20 portability applies to personal data the person provided to a controller when processing is automated and based on consent or a contract. The output must be structured, commonly used, and machine-readable. The person can also ask for direct transmission to another controller where technically feasible, subject to the rights and freedoms of others. The European Commission’s portability overview summarizes these conditions.
This guide is an engineering runbook, not legal advice. Ask privacy counsel to confirm the applicable jurisdiction, role, legal basis, what the request covers, exceptions, and response content.
Do you have to let users export their data?
If EU GDPR applies and Article 20’s conditions are met, the controller must provide covered data in a portable format and may need to transmit it directly where technically feasible. A self-service button is one implementation choice. A controlled manual workflow can handle infrequent requests if it still meets the legal requirements and deadline.
Portability may not apply when processing relies on a legal obligation, public task, legitimate interests, or a non-automated filing system. The person’s Article 15 access right may still apply and can reach personal data beyond Article 20’s narrower “provided by” rule. Classify the request before deciding what the export contains.
If your SaaS processes data for a business customer, the customer may be the controller. Route the request and assist under documented instructions and the data-processing contract. Your SaaS can simultaneously be a controller for separate billing, account-administration, security, or marketing data.
This guide covers the EU and UK GDPR rights. California is a different test: the CCPA, as amended by the CPRA, gives a right to know what a business collected rather than an Article 20 style portability right, applies only to businesses that meet one of its qualifying tests, which include revenue, volume, and deriving most revenue from selling or sharing personal information, and runs on a 45-day substantive response clock after a 10-business-day acknowledgement, per the California Privacy Protection Agency’s consumer FAQ. Classify a California request separately instead of translating this one.
Portability, access, and erasure are different workflows
| Right or task | Primary question | Typical output |
|---|---|---|
| Article 20 portability | Which covered data did the person provide under consent or contract through automated processing? | Structured, commonly used, machine-readable data; direct transmission where technically feasible |
| Article 15 access | Which personal data do you process about the person, and what required contextual information accompanies it? | A copy of covered personal data plus required information |
| Article 17 erasure | Does an erasure ground apply, and does an exception require any data to remain? | Deletion, effective anonymization, restriction, or justified retention by category |
| Vendor migration | Can the product owner move application data and functionality away from a platform? | Platform-specific database, file, code, configuration, and operational exports |
Handling a GDPR erasure request is the other half of that question, but an export script and an erasure worker should never be interchangeable. One produces a reviewed disclosure; the other changes or removes data.
A trustworthy export identifies the right, maps the systems, applies the inclusion rules, protects other people, and proves exactly what was delivered.
What data belongs in a portability export?
The GDPR data portability requirements are narrower than most teams expect: data the person provided, plus data observed from their use of the service, and only where processing is automated and rests on consent or a contract. What your systems inferred about them generally falls outside that. When a covered record includes another person’s personal data, document how disclosure could affect that person’s rights and freedoms, then redact, separate, or apply another proportionate control where needed.
The EDPB-endorsed Article 29 Working Party data-portability guidance treats “provided by” as including data a person actively supplied and data observed from their use of a service. It distinguishes inferred or derived data created by the controller’s analysis.
| Data category | Article 20 portability starting point | Important review |
|---|---|---|
| Actively provided | Usually covered when the other Article 20 conditions are met | Confirm the data concerns the requester |
| Observed through use | Can be covered | Separate the person’s activity from other users and secrets |
| Inferred or derived | Generally outside Article 20’s “provided by” rule | It may still be personal data reachable under Article 15 access |
| Third-party personal data | Requires rights-and-freedoms analysis | Redact, separate, or apply another safe control |
| Internal secrets and security material | Never expose merely because it shares a row | Remove password hashes, tokens, signing keys, internal credentials, and other users’ secrets |
That last distinction fixes a common error: “outside portability” does not mean “the user can never receive it.” A churn score, fraud flag, or model-derived segment may fall outside Article 20 while remaining personal data under Article 15. Counsel should define the response rule, and the export manifest should record which rule was applied.
After mapping inclusion, document the retention side of this same problem. Generated archives, delivery tokens, and work files should have their own short, approved lifecycle instead of becoming a new permanent copy.
Build an export manifest before writing the file
Most published GDPR data portability examples show the finished file. The useful artifact is the row above it. The manifest is the piece that does the real work: it keeps legal classification separate from serialization. Create one row per data source:
| Source | Controller/processor role | Identifier path | Data category | Article 20 decision | Article 15 decision | Third-party review | Export format | Owner and evidence |
|---|---|---|---|---|---|---|---|---|
| Account DB | ___ | auth ID to user ID | Profile fields | Include/exclude + reason | Include/exclude + reason | ___ | JSON | ___ |
| Event store | ___ | user ID | Observed usage | ___ | ___ | ___ | CSV | ___ |
| Object storage | ___ | workspace and object owner | Uploaded files | ___ | ___ | ___ | Original files + index | ___ |
| Billing processor | ___ | customer ID | Transactions | ___ | ___ | ___ | CSV/JSON | ___ |
| Model logs | ___ | request owner | Prompts and responses | ___ | ___ | ___ | JSON | ___ |
| Support system | ___ | verified email/account ID | Tickets | ___ | ___ | ___ | JSON/PDF as appropriate | ___ |
The table makes omissions visible before code hides them. It also shows where a processor API, manual support action, or third-party rights review is required.
At least 5 of 21 third-party apps in the fixed AxonBuild June and July 2026 audit cohort had confirmed PII or PHI exposure. That result does not measure export completeness. It shows why a system-level data map matters: sensitive fields can exist outside the table a developer first labels as user data.
| Weak export | Stronger export |
|---|---|
| One row from the users table | Manifest-reviewed data from every covered system |
| Every column copied with select * | Allowlisted fields with secrets and third-party data removed |
| A file that opened once | A versioned schema, fixture test, secure delivery record, and reproducible verification |
How to build a secure SaaS data export
1. Authenticate and authorize the request
Prefer a recently authenticated session for self-service exports and step up authentication for sensitive data. For manual requests, use a proportionate identity check. Do not collect high-risk identity documents when a lower-risk method is adequate. Resolve the request to an internal subject key before querying systems.
2. Run export work with least privilege
Use a dedicated worker that can read only allowlisted fields and objects. It should not have permission to change production records. Never serialize raw rows with select *, because future schema changes can silently add password hashes, reset tokens, internal notes, or another person’s fields.
Use an explicit output contract instead of treating an application row as the export schema:
| Export section | Include from the approved manifest | Exclude by default |
|---|---|---|
| Envelope | Schema version, generation time, request ID | Internal credentials and worker configuration |
| Profile | Individually approved account fields | Password hashes, reset tokens, internal notes |
| Activity | Approved event type, time, and resource relationship | Other users’ events and internal risk signals |
| Files | Approved original file plus a safe index | Storage credentials, internal paths, unrelated shared files |
The fields are examples, not a legal inclusion list. Generate every field from the approved manifest and test authorization independently for every data source.
3. Choose formats that preserve structure and meaning
CSV works for flat tables, JSON for nested relationships, and original file formats for user-created objects. Include a small README or schema dictionary defining field names, time zones, identifiers, enum values, and relationships. For Article 20 portability, do not rely on PDF as the reusable dataset: the EDPB’s small-business rights guidance says PDF is not sufficient. A PDF can accompany an Article 15 response or explain fields, but the portable records still need a structured, commonly used, machine-readable format.
4. Protect other people and the product
Review shared workspaces, message threads, payments, support conversations, and collaborative documents. Remove or separate third-party personal data where disclosure would adversely affect others’ rights. Exclude password hashes, authentication secrets, private keys, internal access tokens, abuse-detection logic, and unrelated confidential material.
5. Deliver through a controlled channel
Store the generated archive in a private location, encrypt it as appropriate, and issue a short-lived, single-purpose download URL. Notify the requester through a previously verified channel. Avoid ordinary email attachments for sensitive archives. Log creation, access, expiry, and deletion without placing the exported contents in application logs.
Direct transmission to another controller requires destination authentication, authorization from the person, format agreement, transport security, failure handling, and a record of what was sent. “Technically feasible” needs a concrete assessment, not an unsupported refusal.
6. Verify with a fixture user
Create a synthetic user represented in every source, including shared records and intentionally excluded secrets. Generate the export and assert:
- every manifest item marked for inclusion appears once;
- excluded secrets and unrelated user data never appear;
- timestamps, encodings, and field definitions are consistent;
- files open and checksums match the source objects;
- a failed worker can resume without duplicating or widening the export;
- the link expires and the generated archive is removed on schedule.
Keep the schema version, manifest version, code revision, test result, request ID, and archive checksum as verification evidence. Avoid retaining the archive itself merely to prove it once existed.
The separate problem of leaving an app-building platform
A founder may also need to leave a no-code or AI-app-builder platform. That is an operational migration question, not automatically the same legal right a SaaS user has under Article 20. The contract, platform capabilities, database ownership, file access, code portability, and subprocessor setup determine what the founder can retrieve.
Before relying on a platform, test whether you can export database records, uploaded files, authentication mappings, environment configuration, scheduled jobs, and the code or workflow definitions needed to operate elsewhere. A user-data portability feature cannot substitute for that migration plan.
On Lovable specifically, two questions come apart and are worth answering in order. Getting the database out is an export task with a known path. Moving the whole app off Lovable Cloud is a migration, with hosting, authentication and environment configuration attached to it.
The mapping work above uses the same schema discipline that catches the data-loss bugs hiding in an AI-built app. A complete export is one part of launch readiness alongside a backup that has actually been tested, safe deletion, and reliable authorization.
Common questions about exporting user data
What is GDPR export?
It is the file a company produces when someone exercises a GDPR right to receive their personal data, usually Article 20 portability or Article 15 access. The two rights cover different data, so classify the request before building anything. Neither one is a database dump.
What is the GDPR’s right to data portability?
Article 20 lets a person receive the personal data they provided to a company in a structured, commonly used, machine-readable format, and ask for it to be sent straight to another company where that is technically feasible. It applies only where the processing is automated and based on consent or a contract.
What is a data portability request?
It is someone asking for their data under Article 20 rather than under the access right, though in practice it usually arrives as “send me my data”. Data portability means the person can reuse the result somewhere else, which is why format and field definitions matter more here than in an access response. Ask which right applies before you build the file.
What format should a GDPR data export use?
For Article 20 portability, use a structured, commonly used, machine-readable format. CSV can suit flat records; JSON can preserve nested data; original formats can suit uploaded files. Include field definitions so another system can interpret the result.
Are inferred or derived data excluded from every GDPR export?
No. They are generally outside Article 20 portability’s “provided by” rule, but they may still be personal data covered by an Article 15 access request. Classify the request and obtain legal review for exclusions.
How long do I have to respond?
EU GDPR Article 12 generally requires action without undue delay and within one month. A two-month extension may be available because of complexity or the number of requests if the person is informed within the first month and given reasons. Confirm the current rules and jurisdiction with counsel.
Can I email the export as an attachment?
That may expose sensitive data to the wrong mailbox or leave uncontrolled copies. Prefer an authenticated portal or a short-lived secure link, with appropriate encryption, access logging, and archive expiry.
Is a database backup a user-data export?
No. A backup is designed to restore your systems and can contain every user’s records, secrets, and internal state. A user export is limited to one authorized person, reviewed for applicable rights, and delivered in a safe, understandable format.
When the app carries customer access or revenue
AxonBuild fixes the payment, billing, access, or data-handling failure, verifies the result, and adds a check that catches it before it interrupts the business again.
