Data Subject Access Requests (DSARs) can be simple, but they rarely are. As volumes rise and people become more familiar with their rights, organisations are being pushed to clarify exactly what must be handed over and where the line is for saying no. One of the most common questions right now is: do we really have to include Slack messages, Teams chats and every scrap of commentary? Closely followed by: can we push back if a request is just too much?

Let’s unpack both sides of that.

What must be provided (the baseline duty)

Under UK GDPR, individuals have a right to access their personal data. That right is broad. It covers any information that relates to them and can identify them, directly or indirectly.

So the first principle is this: the format or location does not matter. If the data qualifies as “personal data”, and it is in your possession or control, it falls within scope.

That means Slack messages? Yes. Teams chats? Yes. Emails? Certainly. Hidden rows in spreadsheets, message logs, and notes in your CRM? All of these are fair game, as long as the individual can be identified in the data and the data is about them.

A few examples:

• A Slack conversation where colleagues discuss “Jamie’s poor performance” is likely Jamie’s personal data.
• A chat between two people where one says “I had a call with Jamie this morning” may be personal data if the rest of the context is about Jamie.
• A general team-wide announcement, if not personally targeted or identifiable, probably is not.

This applies even if the data is unflattering or includes staff opinions or internal decision-making. As the ICO has said before, opinions about someone can still be personal data, even if they are informal or shared via chat platforms.

What about backups or hard-to-access data?

This is where the 2025 Data (Use and Access) Act (DUAA) changes things slightly. The updated law makes it clear that organisations are only expected to carry out “reasonable and proportionate” searches.

So, while you cannot ignore Slack just because it is messy, you are not expected to restore ten-year-old backups or check every shadow system if there is no real indication that the requester’s data would be there.

What is reasonable will depend on a few factors:

• The nature of the request
• Where the person’s data is likely to be found
• The burden of searching compared with the likely benefit to the requester

In short, you should search all the places where the data is reasonably expected to exist, but you do not have to go to extreme lengths.

Can we refuse to respond at all?

Only in certain cases.

UK GDPR allows you to refuse a request, or charge a fee, if it is “manifestly unfounded or excessive.”

Let’s take those separately.

Manifestly unfounded means the request is made with no real intention of accessing personal data. It might be aimed at harassing the organisation or simply wasting time.

Manifestly excessive means the request is clearly unreasonable, particularly when you look at the time and effort it would take to respond.

But this is a high bar.

A request is not excessive just because it is broad or time-consuming. If someone genuinely wants to access their personal data, and your organisation holds a lot of it, then it is still a valid request.

What might qualify as excessive:

• A repeat request sent shortly after the first, without a clear reason
• A demand for all data ever held across hundreds of systems, where there is no reason to believe most of those systems hold anything relevant
• A request that would involve a huge effort for very little value, such as trawling through archived files from ten years ago for someone who only wants a copy of one payslip

What if the request is vague?

This is where the DUAA has introduced something helpful. It includes a “stop-the-clock” clause.

If the request is unclear or too broad, you can pause the deadline while you ask the requester to clarify.

For example, if someone asks for “all data” and you hold years of records across multiple teams, you might say:

“We’re happy to respond to your request, but it would help if you could clarify what type of data you are most interested in – for example, communications, HR records, or finance documents – or if there are particular dates or teams we should focus on.”

The one-month timer only resumes once they reply. This gives you more time and helps focus the response on what matters most.

Redacting and protecting others

Even when Slack messages and other content fall within scope, not everything can be shared. You still have a duty to protect other people’s data.

So, before sending anything, you need to review and, if necessary, redact:

• Names of third parties, unless it is reasonable to include them
• Comments or views about others
• Confidential business information, in some cases
• Content that is legally privileged or otherwise exempt

Gathering the data is just the start. The review and redaction stage often takes the most time and requires a careful and consistent approach. Mistakes here can lead to breaches.

Final thoughts

Slack messages, Teams chats, and informal commentary can all be in scope for DSARs. If the data is about the requester, and you hold it, you must include it.

That said, you are not expected to go through everything without limits. The DUAA has made clear that searches must be proportionate, and it has introduced helpful tools like the right to pause and clarify vague requests.

Handled well, DSARs do not have to be overwhelming. With clear processes, early engagement, and a good handle on what is and is not required, organisations can stay compliant without burning out.