GDPR Data Export Request Handler for SaaS Products

Under GDPR Article 15, any EU resident whose data you process has the right to request a copy of all personal data you hold about them. You have 30 days to respond. The request can come from any customer, any end user of a customer's account, or any prospect whose email address you collected during a trial. It can come multiple times from the same person. And for complex SaaS products — where customer data lives across your application database, your data warehouse, your CRM, your support ticket system, and your marketing platform — assembling a complete response manually is a significant operational challenge that grows with your business.

A GDPR data export request handler turns this from a fire drill into a repeatable, documented process. The goal is not just to comply but to comply in a way that's consistent, auditable, and fast enough that it doesn't consume disproportionate engineering and ops time at scale.

The Scope of a Subject Access Request

The most common mistake SaaS teams make with subject access requests (SARs) is scope: they pull data from the primary application database and consider the request complete. But personal data under GDPR means any information relating to an identified or identifiable natural person — a definition that is intentionally broad.

For a typical SaaS company, personal data lives in multiple systems: your primary application database (account records, profile data, content the user created), your support system (ticket history, email conversations, chat transcripts), your CRM (contact records, sales notes, call logs, opportunity history), your analytics platform (behavioral event data, session recordings), your marketing platform (email open history, campaign enrollment, form submissions), your billing system (payment method metadata, invoice history, subscription changes), and your data warehouse (historical snapshots, analytics transformations built on top of raw events).

A complete SAR response must cover all of these systems. That's not optional — omitting data from systems you chose not to query is still a compliance gap, and regulators are explicit that "we didn't check that system" is not an acceptable response to a request.

The handler defines the system inventory — every system that may hold personal data — and queries each one as part of the response workflow. Systems with API access are queried automatically; systems without API access have a manual export step that's required to be completed before the response can be delivered, ensuring completeness even for legacy or third-party systems.

The Request Intake Workflow

The intake workflow handles the steps between a request arriving and the data collection beginning. These steps are more consequential than they appear.

Identity verification. Before processing a SAR, you must verify the identity of the requestor — you cannot send personal data to someone who may not be the subject. Without verification, you risk inadvertently disclosing one person's data to another who claims to be them. The verification workflow requires the requestor to confirm their identity through a method that confirms they control the email address in question. For B2B SaaS, verification may also involve confirming the requestor's relationship to a customer account — an end user of a customer's workspace has different data rights than the customer organization itself.

Requestor scope clarification. For B2B SaaS products where a user may have data across multiple workspaces, organizations, or historical accounts, scope clarification prevents both over-disclosure and under-disclosure. The handler asks: which workspaces do you want data from? Do you want data from your historical account before your company migrated to the current workspace? This step is particularly important when user identifiers have changed over time — email address changes, account mergers, or multi-workspace access.

Request ID and 30-day clock. The handler generates a unique request ID and starts the compliance clock on intake. The 30-day deadline from GDPR is binding, not aspirational. The handler tracks days remaining against the deadline and escalates to the responsible team if the request is approaching the deadline without a completed response. Extensions of up to an additional 60 days are permitted under GDPR for complex requests, but must be communicated to the requestor within the initial 30-day window — the handler surfaces this requirement at the appropriate point.

Duplicate request detection. The same individual can submit multiple SARs, and subsequent requests while the first is in flight need to be handled carefully — either by consolidating them with the active request or by documenting the relationship between requests in the audit trail.

Data Collection and Assembly

The handler queries each system in the inventory and assembles the results into a structured format. The assembly process has several requirements that are easy to underspecify.

Attribution. Each piece of data in the export should be attributed to its source system. The requestor should be able to understand where each item came from: "this profile data is from your account in our application; this email history is from our marketing platform; this billing record is from our payment processor." Attribution enables the requestor to identify discrepancies and to make informed follow-up requests if they believe the export is incomplete.

Format selection. GDPR specifies that personal data should be provided in a "commonly used, machine-readable format." For most SaaS products, JSON is the technically appropriate format; for requestors who aren't developers, a human-readable PDF summary is more useful. The handler should support both, either as separate outputs or as a combined package where the JSON is included in a ZIP alongside a human-readable summary.

Structured vs. unstructured data. Structured data — database records, event logs — is straightforward to query and format. Unstructured data — email threads, support conversation text, notes added by a sales rep — requires extraction and formatting decisions. The handler should have defined processing rules for each data type rather than leaving this to whoever is processing the current request.

Sensitive field handling. Some fields in your database contain sensitive data that warrants special handling in exports: hashed passwords (include the hash or indicate its existence without including it), partial payment card data (include only the last four digits and card type), internal notes written by your staff (include them in the export, as they relate to the individual). The handler encodes these decisions consistently rather than leaving them to per-request judgment.

Secure Delivery

The assembled data export must be delivered securely. Emailing a ZIP attachment of someone's personal data is not appropriate — email is not a secure channel for data transfer.

The handler generates a secure, time-limited access link to the export package. The link is authenticated — the requestor must verify their identity again to access the download, not just possess the URL. The link expires after a defined window (7–14 days is appropriate, giving the requestor time to download without indefinitely exposing the data). Access events are logged — the handler records when the link was generated, when it was accessed, and from what IP, providing a complete delivery record.

For requestors who need a different delivery mechanism — due to accessibility needs or their country's specific requirements — the handler supports alternative delivery methods with appropriate security controls and documentation in the audit trail.

The Audit Trail That Demonstrates Compliance

The audit trail is what transforms a compliance process into a demonstrable compliance record. Without a structured audit trail, "we comply with GDPR SARs" is a claim that can't be substantiated when challenged. With one, it's a factual record that can be produced on demand.

Every SAR generates a complete, tamper-evident audit record: when the request was received, the request ID, which verification steps were completed and when, which systems were queried as part of data collection, which systems required manual export steps and who completed them, when the data package was assembled, when the secure delivery link was generated, when it was accessed. This record is what you produce if a supervisory authority asks how you handled a specific request — or if the requestor disputes that they received a complete response.

For SaaS companies operating at scale — thousands of users across hundreds of customer accounts — manual tracking of these records is operationally impossible. The handler makes audit trail generation automatic and consistent regardless of which staff member is processing the request.

Handling Edge Cases That Break Manual Processes

Manual SAR handling breaks down on edge cases in predictable ways. A few that the handler needs to address explicitly:

Accounts associated with multiple email addresses. Users frequently change email addresses, have multiple accounts, or have data under a personal email and a work email. The handler should support multi-identifier lookups that surface data associated with any verified identifier the requestor provides.

Data about the requestor in other users' accounts. In B2B SaaS, a user's name or contact information may appear in records created by other users — a sales rep's notes mentioning a contact who later submits a SAR, for example. These references are also personal data. The handler needs a defined policy for whether and how to include this "third-party context" data, and that policy should be reviewed with legal counsel.

Requests from former employees or users. Data from inactive accounts often lives in different storage — archived databases, cold storage, backup snapshots. The handler's system inventory should include inactive account data stores, and the response workflow should account for the additional time and access required to retrieve data from these systems.

Children's data. If your product may have collected data from users under 16 (the GDPR age threshold in most EU countries), SARs involving minors require additional handling. The handler should flag accounts with potential age-related issues for manual review rather than automating the response.

The Connection to the Right to Erasure

GDPR also includes the right to erasure under Article 17: the right to have personal data deleted. The SAR handler is the natural companion to an erasure workflow — the same system inventory, the same verification process, the same 30-day deadline, the same audit trail requirement — with deletion rather than export as the final action.

Building both together reduces implementation cost meaningfully. The system inventory, the identity verification workflow, the audit trail infrastructure, and the operator interface are shared between both workflows. The data collection logic for SARs and the deletion logic for erasure requests query the same systems, just with different operations. Teams that treat these as separate builds spend significantly more than teams that design them as two output modes of the same compliance infrastructure.

The combined SAR-plus-erasure system is also more coherent from an operator's perspective. The team that handles one also handles the other; the tooling is consistent; training and documentation apply to both. A single compliance request management interface is meaningfully easier to operate than two separate tools with different interfaces and different audit logs.