When Someone Asks for Their Data Back: DSRs and Why B2B Companies Can't Ignore Them

Most B2B software companies I work with don't think data subject access requests are their problem. They're not selling to consumers, they're not collecting marketing lists, and they're certainly not the type of company that ends up in the news for a privacy breach. And then one day, an email lands in their support inbox from someone they've never heard of, asking for all the personal information the company holds about them.

Welcome to the world of data subject rights (DSRs). Let's talk about what they are, why they're your problem even if you're purely B2B, and why acting on them too quickly can cause just as much trouble as ignoring them.

What We're Actually Talking About

Depending on which jurisdiction you're operating in, individuals have varying rights over their personal information. At a basic level, the rights that most commonly come up are: the right to access (what do you hold about me?), the right to deletion (erase it), and the right to opt-out of certain processing. In the EU under GDPR, you'll also encounter portability (give me my data in a usable format) and correction (fix inaccurate information about me). These aren't optional, and they come with response time limits, some as short as 30 days.

The B2B Trap

Here's where it gets interesting. You're a software company, your clients are businesses, and your product processes data on their behalf. When a data subject contacts you directly, your instinct might be to help them out, action the deletion, send them what you've got, and close the ticket. That instinct can land you in serious trouble.

If you're processing personal data on behalf of a client, you are almost certainly a data processor under GDPR (and a service provider under various North American equivalents). That means your client is the controller. They own the relationship with that individual. They decide what happens to that person's data, not you.

When you delete or disclose data because someone asked you directly, without consulting your client first, you may be acting outside of your Master Services Agreement or Non-Disclosure. You could be exposing your client to compliance risk. And under GDPR in particular, acting unilaterally could inadvertently pull you into controller territory, which carries a considerably heavier set of obligations than you signed up for.

What should happen instead is this: the request comes in, you acknowledge it, and direct the individual to the client. They assess it, instruct you accordingly if needed, and you act only on their instruction. Your policy should document exactly that process. If your client fails to respond within a reasonable timeframe, then and only then is there an argument for stepping in to protect the individual. But the starting point is always the client.

Don't Forget Your Own Employees

The other side of this that catches companies off guard is employee DSRs. Your own staff have rights too, and an access request from an employee is considerably more complex than one from a customer.

Think about the volume of data you hold on a single employee: emails, messages in Slack or Teams, HR records, performance reviews, work tracking tools, engagement surveys, and more. A right of access requires you to compile and review all of that, redact third-party information appropriately, and respond within the legal time limit. Depending on the size of your team and the tools you use, this can put your HR and IT staff out of action for the entire response window.

Having a policy in place that covers how employee DSRs are handled, who coordinates the response, and what systems need to be searched is not just good practice. It's something you should have well before you need it.

What This Means in Practice

The practical takeaway here is simple: you need a documented procedure for handling data subject requests. It needs to distinguish between requests that relate to client data (which should be routed to the client) and requests that relate to your own employees (which require a defined internal process). And it needs to reflect the time limits imposed by the legislation in the jurisdictions you operate in.

If you're unsure where to start, or if a request has already landed on your desk and you're not sure what to do with it, that's exactly the kind of situation I help companies work through. Feel free to reach out, and if you'd like me to come in and walk your team through how to handle these situations in practice, I'm happy to do that too.