GDPR DSARs for AI-Built Apps: A Founder's Response Checklist

TL;DR: A customer sends a GDPR data subject access request (DSAR). Your app runs fine. But there's no data map. That's where the first week of your one-month deadline goes. Article 15 says you must confirm what personal data you process. You must give a copy of it. You must explain the purpose, who you shared it with, how long you keep it, and where it came from. You get one month to respond. You can extend once, by up to two months, for complex or high-volume requests, if you notify the requester within the first month. AI-built apps usually struggle here for one reason. Personal data is scattered across auth tables, webhook logs, analytics events, email tools, and support tickets. Nothing connects them. This is a checklist for finding it all before the clock runs out.

A founder ships a working SaaS built with an AI coding tool. Signup works. The dashboard works. Then an email arrives. Someone wants a copy of everything you hold about them, under GDPR Article 15. Nobody on the team has ever built that export before. The app was never the hard part. The data map was.

What GDPR Article 15 requires

A DSAR is not just "send them their data." Article 15 sets the bar higher. Your reply must let the person see what you processed. It has to explain why, and who else saw it. At minimum, that means:

• Confirmation of processing — are you processing personal data about them, yes or no.
• A copy of the personal data you hold about them.
• The purpose of the processing.
• Categories of personal data involved.
• Recipients or types of recipients, including any third parties.
• The retention period, or the rule you use to set it.
• The source of the data, if you didn't collect it directly from the person.
• Their other rights: fix data. Delete it. Limit its use. Or file a complaint.

An AI coding tool can build a working product without building any of this. Speed and paperwork are not the same thing. A DSAR only tests the second one.

The one-month clock, and the one-time extension

Your default deadline is one month from receipt. GDPR allows a one-time extension of up to two months. This is only for requests that are complex or high-volume. To use it, notify the requester within the first month. State the reason.

That extension is a safety valve. It is not a plan. If you only learn how scattered your data is on day 25, you've already lost the chance to notify on time.

Why AI-built apps struggle with DSAR exports

Say you shipped with Lovable, Bolt, Cursor, Replit, v0, or Claude Code. Your GDPR posture is probably incomplete in one specific way. The app works. But nothing forced anyone to write down where personal data ends up once it leaves the signup form. That's not a shortcut someone took. A tool built to run fast does not explain what it stores.

DSAR exports fail for a simple reason. Personal data ends up in places that were never meant to hold it. You can have a clean, well-indexed users table and still miss the request. The rest of a person's data can live somewhere else. Webhook logs. Analytics events. Email systems. A support ticket thread nobody thought to check.

We've audited 700+ AI-built apps. Access-control and data-exposure gaps are some of our most common findings. Those are the same kinds of gaps that make a DSAR export incomplete or risky. A team that hasn't mapped its data before a DSAR arrives usually hasn't locked it down either.

Where personal data hides in an AI-scaffolded stack

Most DSAR surprises happen in places nobody thought of as "data stores." Common hiding spots include:

• Auth and identity tables — email, name, IDs, password-reset events, account status.
• Profile and preference tables — onboarding answers, roles, settings.
• Message and generation history — chat logs, prompts, AI outputs, feedback.
• Webhook logs — raw request bodies and headers, retries, status updates.
• Third-party analytics — event data that carries a user ID.
• Email tools — delivery IDs, campaign IDs, click-tracking data.
• Support ticket systems — messages, attachments, transcripts.
• Payment systems — invoices, refunds, and any customer data you copied into your own tables.
• LLM or AI provider logs — if your app calls an LLM, you may store prompts, outputs, or request data.
• Background jobs and retry queues. Queued data can hold personal data long after the original request finished.

It's where your users live, not where your office is, that triggers these rules. If you built for EU customers in 2026, DSAR readiness is not optional busywork.

What to redact, and what you can't

A DSAR means you must hand over the requester's personal data. It does not mean you must hand over someone else's private data. It does not cover your real trade secrets, or internal notes that aren't about the requester. Typical redaction needs:

• Third-party personal data in messages, logs, or tickets — another user's name or email, for example.
• Anything that would harm someone else's rights if you disclosed it.
• Real trade secrets and confidential business logic.
• Internal notes, where they aren't personal data about the requester, or would hurt someone else's rights.

Don't over-redact, though. If it's personal data about the requester, the default is to hand it over. Don't withhold it just because it's inconvenient. When unsure, export what you can justify. Write down your reasoning.

A step-by-step DSAR response checklist

1. Log the request right away, with a timestamp. Now your one-month clock is real, not a guess.
2. Confirm it's actually a DSAR. Check if the person wants Article 15 access only, or other rights too.
3. Verify identity, but keep it light. Use signals you already have — a logged-in session, or a verified email. Don't ask for more ID than the risk calls for.
4. Judge the complexity early. If the request needs many table joins and third-party pulls, plan for the time. Prepare to notify within the first month if you'll need the extension.
5. Build a data-pull map keyed to the requester's ID — email, user ID, or auth ID. List every table and tool that could hold data linked to it. Include webhook logs, support tickets, analytics events, email tools, and AI logs if you store prompts or outputs.
6. Export the data in a readable bundle. Group it by category: profile, account activity, messages, billing, support, AI interactions. Keep raw data only where you need it. Redact the rest.
7. Write the Article 15 explanation. Cover purpose, categories, recipients, retention, and source, where it applies.
8. Redact third-party data and trade secrets before you send anything.
9. Send the response through a channel that matches the verified identity. Write down what you sent, and when.
10. Close the loop. Record the outcome. Update your data-pull map. Every request shows you what your AI-built stack didn't write down on its own.

If your stack runs on Supabase, use the same discipline for row-level security while you're at it. Is RLS on for every table? Are the policies scoped to the owner, not written as USING (true)? RLS isn't an Article 15 rule. But it's what stops a DSAR export from grabbing someone else's rows by mistake.

Reduce next quarter's DSAR risk

Once a DSAR lands, you're already firefighting. The cheaper path is to treat DSAR readiness as a habit, not a one-time scramble:

• Run platform-aware scanning to find gaps in access control and data exposure — weak or missing checks around export endpoints, for example.
• Do a dry-run export for one test user. See how many systems you missed.
• Map your retention rules across databases, backups, and third-party tools.
• Make the export repeatable. The next request should take hours, not a fire drill.

This same data map helps with EU AI Act transparency rules too. Both need you to know what your system stores, and how it uses what users send it.

Paperwork is only half the picture

A DSAR checklist gets you through one request. It doesn't fix the gap that made the request hard in the first place. Our GDPR data mapping guide shows you how to build the map this article assumes you already have. Our GDPR compliance guide for vibe-coded apps covers the product side. Consent records. Retention limits. Deletion flows. Do your AI coding tools ever touch real user data? Our DPA guide for AI coding tools covers the vendor side of that problem. Does your app have an AI feature EU users interact with? Our EU AI Act compliance guide covers when a separate disclosure applies.

Before the next DSAR: know what's exposed

Finding everywhere a person's data lives is a discovery problem. It's the same problem vulnerability scanners solve. They map your app's attack surface. Comparing tools for that kind of pre-audit visibility? See how we compare to Burp Suite. Or read our comparison with Intruder. Either one can surface forgotten endpoints and data stores. Find them now, not while a DSAR clock is running.

What to run next

Start with a dry-run DSAR export for one test user, using the checklist above. Note every system you had to check that you didn't expect to. Then run a free scan against your live URL. See if the same gaps show up: weak access control, exposed data, a missing map. If something serious turns up, our Launch Readiness Audit gets a security engineer to verify it. You get a fix list, not just another finding. Want broader coverage beyond GDPR? Our Compliance Score checks GDPR alongside EU AI Act, SOC 2, ISO 27001, and HIPAA foundations, in one pass.

FAQ