What Happens When My App Gets a Data Subject Access Request?

Most app owners think their biggest worry is getting users to download their app in the first place—but here's something that catches a lot of people off guard. A growing number of apps receive formal data requests from their users, and many app developers have absolutely no idea how to handle them properly. I've seen brilliant apps with thousands of active users brought to their knees by a single data subject access request they weren't prepared for. And the fines? They can be massive if you get it wrong.

A data subject access request (or DSAR for short) is basically when someone asks to see all the personal information you've collected about them through your app. Sounds simple enough, right? But here's the thing—most apps collect way more data than their owners realise. We're talking about everything from basic account details to location history, in-app behaviour, device information, and sometimes even data you've received from third-party services. When that request lands in your inbox, you've got 30 days to gather it all up and send it over in a format people can actually understand.

The challenge isn't just technical; its about having processes in place before you desperately need them

I mean, this isn't some theoretical problem that might happen one day. If your app has users in the UK or EU, you're legally required to handle these requests properly under GDPR. Get it wrong and you could face complaints to the ICO, damage to your reputation, or fines that make your eyes water. But don't panic yet—once you understand what's actually involved and set up the right systems, handling DSARs becomes just another part of running your app properly. Let's walk through exactly what happens when one of these requests comes through your door.

What Is a Data Subject Access Request?

Right, so a Data Subject Access Request—lets just call it a DSAR because that's what everyone says—is basically when someone asks to see all the personal information you've collected about them. Simple as that really.

Under GDPR (and similar privacy laws around the world), people have the legal right to know what data you're holding about them, why you're holding it, who you've shared it with, and how long you plan to keep it. They can also ask you to correct information thats wrong, delete it entirely in some cases, or even move it to another service. The thing is—and this is where it gets a bit tricky for app developers—you have to respond to these requests within 30 days, and you cant charge them for it unless the request is clearly unreasonable or excessive.

I mean, when you're running a mobile app that collects user data (and lets be honest, pretty much every app does these days), you need to be ready for these requests. They're not optional. They're not something you can ignore or put off. You see, the penalties for not handling DSARs properly can be massive—we're talking up to £17.5 million or 4% of your annual global turnover, whichever is higher. Bloody hell, right?

But here's the thing—most DSARs aren't from angry users trying to catch you out. Often they're from people who genuinely want to understand what data exists about them, or maybe they're moving to a competitor and want to take their information with them. Sometimes its from someone who's had their account compromised and wants to see what damage was done. Understanding this helps you approach DSARs with the right mindset; they're a legal obligation, sure, but they're also an opportunity to show users you respect their privacy and take data protection seriously.

Why Your App Might Receive a DSAR

Right, so you've built an app that collects user data—and lets be honest, if your app does anything useful at all, it probably collects some form of data. Maybe its just an email address and a password. Maybe you're tracking how people use certain features. Or maybe you've got payment details, location data, health information, or chat messages stored away somewhere. Whatever you're collecting, theres always a chance a user will submit a data subject access request to see what you've got on them.

The most common reason people submit these requests? They're genuinely curious about what information companies have collected about them. Its become more mainstream now—people are more aware of their rights under GDPR and they want to see exactly what data exists about them in your database. Sometimes they just want to know if you're handling their information responsibly; sometimes they're checking before they delete their account. Just like when you're building an email list before your app launches, understanding user motivations helps you prepare for their requests and expectations.

Common Triggers for DSARs

Here are the situations where you're most likely to receive a request:

• A user is planning to close their account and wants to download their data first
• Someone's concerned about a privacy breach they've heard about (maybe not even related to your app)
• A user disagrees with how you've used their data or what recommendations your app is showing them
• They're involved in a legal dispute and need evidence of their interactions
• A parent wants to see what data you've collected on their child
• An ex-employee wants to retrieve communications or information from when they used your work account

And then theres the reality that some people submit requests just because they can—testing your systems or seeing how responsive you are. I've seen apps receive requests from security researchers who are evaluating your data practices, or even from competitors trying to understand how your app works. Whatever the reason, you're legally obligated to respond properly within 30 days.

If your app operates in healthcare, finance, or handles children's data, expect more DSARs than average. These are high-sensitivity areas where users are rightfully more protective of their information.

What Information You Need to Provide

Right, so someone's made a data subject access request to your app—now you need to know exactly what information you're legally required to hand over. And I'll be honest, this is where a lot of app owners get it wrong because they either give too little or way too much. Let me break down what you actually need to provide.

First up, you need to confirm whether you're processing their personal data at all. Sounds obvious but its worth stating. If you don't hold any data about them, you can tell them that and you're done. But if you do have their data? Here's what they're entitled to receive:

The Must-Include Information

• A copy of all personal data you hold about them—this includes profile information, account details, usage data, location history if you collect it, payment information, and any other data tied to their identity
• The purposes of processing (why you collected and use their data)
• The categories of data you hold (what types of information you've got)
• Who you've shared their data with—third-party services, analytics providers, payment processors, the lot
• How long you plan to keep their data
• Where the data came from if you didn't collect it directly from them
• Whether you're using automated decision-making or profiling
• Their rights to request correction, deletion, or restriction of processing

Now here's the thing—you need to provide this in a format that's actually readable and understandable. I mean, you can't just dump a database export on someone and call it a day, even though I've seen companies try that! The information needs to be clear, concise, and in plain language. Most apps provide this as a PDF or structured document that walks through each category of data systematically.

One thing that catches people out is third-party data. If your app uses analytics tools, push notification services, or payment gateways, you need to disclose what data flows to those services. You don't need to provide the data those services hold (they're separate data controllers) but you do need to tell the user that you share data with them and for what purpose.

The 30-Day Response Timeline

Right, so here's where things get a bit time-sensitive—when someone sends you a data subject access request, you've got 30 calendar days to respond. Not working days, calendar days. That includes weekends, bank holidays, Christmas... all of it. The clock starts ticking from the moment you receive the request, not from when you get around to reading it or when you think its legitimate.

I mean, 30 days sounds like ages when you first hear it? But trust me, it goes fast. Really fast. You need to identify the person making the request, verify their identity (which can take a week on its own), locate all their data across your entire system, compile it into a readable format, redact any third-party information that shouldn't be shared, and send it back in a way they can actually use. We've built systems for apps that store user data in five different places—the main database, analytics platforms, customer support tools, backup systems, and sometimes even in email chains. Finding everything takes time.

The 30-day timeline isn't a target to aim for; its the absolute maximum you're allowed, and regulators expect you to respond sooner when the request is straightforward

When You Can Extend the Deadline

In some cases, you can extend the deadline by another 60 days if the request is particularly complex or if you're dealing with multiple requests from the same person. But—and this is important—you need to tell the person within the first 30 days that you're extending the timeline and explain why. You cant just go silent and hope they forget about it. That's when complaints get filed and regulators start asking questions.

What Happens If You Miss It

Miss the deadline without a good reason and you're opening yourself up to complaints to the ICO or whatever data protection authority covers your users. The fines can be substantial, but honestly the reputational damage is often worse for apps; word spreads fast when a company ignores user data rights.

How to Handle DSARs in Your App's Backend

Right, so you've received a DSAR and you need to actually pull the data together. This is where having a properly structured database really pays off—or where you discover that your backend is a bit of a mess (been there, trust me). The first thing you need to do is identify every single place where you store user data. I mean every place. Your main database, sure, but what about your analytics platform? Your crash reporting tool? That third-party payment processor? It all counts.

Here's the thing—most apps store user data in way more places than you think. You've got your primary database tables, log files that might contain personally identifiable information, backup systems, CDN caches if you're storing profile images, email marketing platforms, customer support ticket systems... the list goes on. Each of these needs to be checked and the relevant data extracted. Its not just about pulling one database table and calling it a day.

What Your Backend Needs to Support

Your system should be able to search across all data stores using a unique identifier—usually email address or user ID. Some developers build a dedicated DSAR endpoint that automatically queries all relevant databases and compiles the results into a single export file. That's the smart way to do it, honestly. If you're still manually querying different systems one by one you're going to waste hours every time a request comes in.

Format and Delivery Considerations

The data needs to be provided in a format that's actually readable by humans. JSON dumps are fine if your user is technical, but CSV or PDF usually works better for most people. You also need a secure way to deliver the data—email isn't great for sensitive information, so consider setting up a secure download portal with time-limited access links. And don't forget to log every DSAR you process; you need an audit trail showing when requests were received, what data was provided, and when it was delivered. This protects you if questions come up later about how you handled the request.

One more thing—test your DSAR process regularly by submitting requests for test accounts. You'll be surprised what you find when you actually go through the process yourself; missing data connections, broken export scripts, or data thats stored in places you completely forgot about. Better to discover these issues during testing than when you're racing against that 30-day deadline.

Common Mistakes That Can Cost You

Right, lets talk about the mistakes I see app owners making when they get their first data subject access request—and trust me, some of these are proper headaches that could have been avoided. The biggest one? Not having any process in place at all. I mean, if you're collecting user data (and spoiler alert, every app does in some way), you need a plan for when someone asks for it back. Sitting there scrambling to figure out where everything's stored whilst the 30-day clock is ticking is not a fun experience.

Another massive mistake is only providing some of the data. You might think "oh, I'll just give them their profile information and that'll do"—but that's not how it works. You need to provide everything you hold on that person. Every log file, every interaction, every piece of analytics data where they can be identified. Missing stuff out, even accidentally, can land you in hot water with the ICO.

Mistakes That'll Cost You Time and Money

Here are the most common errors I've seen over the years:

• Asking users to pay for their data (you cant charge for a DSAR, its illegal)
• Taking longer than 30 days without communicating why
• Providing data in a format that's impossible to read or understand
• Not verifying the person's identity properly before sending sensitive data
• Ignoring requests that come through social media or email instead of official channels
• Deleting data immediately after providing it when you actually need to keep processing records

Set up a dedicated email address just for data requests (like privacy@yourapp.com) and make sure multiple team members can access it—you don't want a DSAR sitting unread because one person's on holiday.

The verification mistake is particularly tricky because you need to balance security with compliance. You can't just send someone's entire data history to any email address that asks for it, but you also cant make the verification process so difficult that it becomes an unreasonable barrier. I usually recommend a two-step verification that matches whatever authentication method your app already uses; if someone logs in with email and password, verify them the same way for their DSAR.

Setting Up a DSAR Process Before You Need One

Right, so here's what I tell every client who comes to me with an app—whether its a tiny startup or a massive company with millions of users. Set up your DSAR process now. Not next month, not when you get your first request, but right bloody now. Because I've seen what happens when an app gets its first DSAR and nobody has a clue where the user data even lives; it's chaos, and you've only got 30 days to sort it all out.

The thing is, setting up a proper process isn't actually that complicated if you do it before the pressure is on. Start by documenting where every piece of user data lives in your system—your databases, your analytics platforms, your email marketing tools, your payment processors. Everything. This sounds tedious (and honestly, it is a bit) but without this map you're going to waste days just trying to find all the data when a request comes in.

Your DSAR Response Checklist

I always recommend my clients create a simple checklist they can follow when a DSAR arrives. Here's what should be on it:

• Verify the requestor's identity (seriously important—you cant just hand over data to anyone who asks)
• Log the request in your tracking system with the date received
• Pull data from all your documented sources within the first week
• Remove any data about other users that might be mixed in
• Format everything in a readable way (spreadsheets work fine)
• Send the response with clear explanations of what each data point means
• Keep a copy of what you sent for your records

Building Your Response Template

Another thing that saves you massive amounts of time? Having an email template ready to go. Not just for the final response, but also for acknowledging the request when it comes in—users appreciate knowing you've received their request and are working on it. Trust me, these small touches make the whole process smoother and they show you're taking data protection seriously, which matters more than people think it does.

Conclusion

Look—handling data subject access requests doesn't need to be the scary legal nightmare that keeps app owners up worrying. Sure, its a serious responsibility and you need to get it right, but once you've got a proper process in place? It becomes just another part of running your app, like handling customer support tickets or managing server updates.

The key thing I've learned from helping clients navigate this stuff over the years is that preparation makes all the difference. If you wait until you get your first DSAR to figure out where your users data lives and how to extract it—well, that's when you're in trouble. The 30-day clock starts ticking immediately and trust me, trying to build a data extraction system under that kind of pressure is not fun for anyone involved.

But here's the thing—setting up a solid DSAR process actually forces you to understand your own data architecture better, which is valuable anyway; you'll spot inefficiencies, discover data you're storing that you dont actually need (and probably shouldnt be keeping), and generally tighten up your whole data handling operation. It's like doing a proper audit of your apps data practices, which is something every app should do regularly regardless of GDPR.

What really matters is that you treat data requests as what they are: a fundamental right that your users have. Build your systems with that respect built in from day one. Document everything. Test your process before you need it. And when that first request comes through? You'll handle it calmly and professionally because you've already done the hard work. That's the difference between apps that treat privacy as an afterthought and ones that build it into their foundation.