If you work anywhere near data protection, compliance, HR, or legal in Ireland right now, you already know the feeling. An email lands in the inbox with the subject line “Subject Access Request” and your stomach drops a little. You know what’s coming: weeks of searching through inboxes, arguing about scope, worrying about what you might have missed, and the nagging fear that whatever you send back still won’t be enough.
That feeling is exactly why Complete GRC and Nuix ran a webinar last week called “Solving the DSAR Challenge,” hosted by Nollag Conneelly of Complete GRC alongside Mark Hastead from Nuix. Close to 60 people attended live, and the conversation that followed was one of the more candid, practical discussions of subject access request handling you’re likely to come across. This post pulls together the key themes from that session, and if you want the full picture, the recording is available to watch below.
The Scale of the Problem, According to the Data Protection Commission
Nollag opened with numbers, and they’re worth sitting with for a moment. According to the Data Protection Commission’s own annual reporting, subject access requests under Article 15 remain the single largest category of complaint the DPC receives, accounting for around 42 percent of all concerns raised. That’s not a one-off spike either. It’s been the top issue for two years running.
The volume tells its own story. The DPC received over 16,000 new cases in 2025, a rise of roughly 45 percent in a single year. Given that organizations dealing directly with clients are already seeing requests continue to climb, it’s plausible that 2026 could push past 20,000 cases. Complaints specifically about the right of access rose by 42 percent, totaling around 1,280 cases, and administrative fines connected to non-compliance have reached into the billions since 2018, with a substantial chunk of that landed in 2025 alone.
The audience polls during the webinar backed this up in a very human way. Most attendees said their organizations receive somewhere between 11 and 100 DSARs a year, with 13 percent handling more than 500. When asked who typically submits these requests, 44 percent said members of the public, 37 percent said service users, and 20 percent said staff. Nollag made an interesting observation here: while public sector and service-facing organizations see more volume overall, staff requests are often the more difficult ones to navigate, precisely because of the underlying employment disputes, grievances, or breakdowns in trust that usually sit behind them.
Why DSARs Go Wrong
The middle section of the webinar dug into the actual mechanics of failure, and this is where a lot of attendees seemed to recognize their own organizations.
The first issue is context. The vast majority of subject access requests, by the DPC’s own analysis and by Complete GRC’s experience with clients, arise out of adversarial situations. Deteriorating employee relationships, financial disputes, service complaints. These aren’t neutral information requests. They’re often the opening move in a longer conflict, and that changes how they need to be handled.
Then there’s the clock. Organizations have one calendar month to respond, extendable by a further two months only for genuinely complex requests. Nollag was blunt about this: 30 days should be the norm, and 60 should be the rare exception for long-term employees or particularly complex cases. Too many organizations default to using the extension as a matter of course, which the DPC does not view favorably.
Transparency failures were flagged as another recurring theme in DPC findings across 2025. Organizations often fail to properly explain to the data subject what they actually did to fulfil the request. And then there’s the third-party data problem: personal information belonging to colleagues, clients, or other individuals ending up in a response when it should have been withheld or redacted.
Underneath almost all of these problems sits what the panel called “the Microsoft problem.” As Nollag put it, 99 percent of the organizations Complete GRC works with run on Microsoft, and Microsoft Purview becomes the default tool for search. The trouble is that Purview isn’t a forensic tool, it’s a compliance and eDiscovery feature bolted onto a productivity suite, and its practical usefulness depends heavily on which license tier you’re on. Many organizations discover, mid-DSAR, that they don’t actually have the search capability they assumed they had.
Even when the search does run, Purview tends to return everything. Nollag described a recent case where an initial search returned over 6,000 documents for a single request, most of which were duplicates, out-of-office replies, automatic notifications, and irrelevant chatter like barbecue invites and Christmas party emails. In one particularly memorable example, a data subject who had submitted a DSAR themselves and pulled their own Purview export back received a single zip file that contained 81 further zip files, each containing more folders and files. Making sense of that structure, tracking what had already been reviewed, and avoiding duplicated effort became close to impossible.
And because Purview searches modify or narrow the working data set as you refine them, rather than working from a stable index, teams often end up re-running searches from scratch, losing confidence in whether they’ve actually captured everything. The result, as Nollag summarized it, is more time spent, more cost incurred, more review hours burned, and ultimately less confidence that the final response is actually complete.
How Nuix Approaches the Problem Differently
This is where Mark Hastead took over to walk through the Nuix platform, and the framing he offered was useful: think of Microsoft Purview as the jack you keep in the boot of your car. It’s fine for the job it’s built for, and it will get you out of a jam. But if you were building a garage, you wouldn’t rely on it. You’d invest in the pneumatic jack designed specifically for the job, built to handle volume safely and repeatedly. Nuix, Mark explained, was built as forensic software from the ground up, largely due to its long history supporting police investigations, and that forensic foundation is now being applied directly to the DSAR problem.
The process Mark described breaks down into several distinct stages, each one narrowing the volume of data a reviewer actually has to look at, while keeping the original data set completely untouched and recoverable at any point.
Deduplication comes first. Using hash identification, the tool identifies and consolidates files that are functionally identical, collapsing dozens of copies of the same out-of-office reply or staff notification into a single reviewable instance. In the example discussed on the call, this step alone took an initial haul of over 6,000 documents down to just over 2,000.
Email thread intelligence comes next. Rather than presenting dozens of fragmented, duplicated emails from the same conversation, the system reconstructs entire threads into a single, readable format, branches and all. A reviewer can then read through one coherent conversation instead of piecing together fragments across a dozen separate files.
Triage by document type follows. The system recognizes that certain file types carry more personal data risk than others. Emails, Word documents, and scanned PDFs typically warrant closer scrutiny, while something like a large Excel spreadsheet full of operational figures might contain almost nothing personal beyond a name in one column. Nollag gave a particularly vivid example here: a batch of 40 staff roster spreadsheets could be identified, recognized as containing nothing more than names and employee numbers, and excluded from full manual review in one step, rather than redacting 30-page spreadsheets one at a time.
AI-assisted iterative search is where the more sophisticated work happens. This allows reviewers to search not just for explicit names but for context. If an employee is referred to by a nickname, an initial, or in a way that doesn’t directly name them but clearly identifies them to anyone who knows the workplace, contextual search can surface that material. Both speakers were careful to stress that this process is machine-assisted rather than automated. Every decision about what is relevant, in scope, or out of scope is made by a human reviewer, which matters both for compliance under the EU AI Act and, frankly, for confidence in the final output. Labels and bookmarks can also be applied at this stage, allowing organizations to build multi-level review workflows where a second or third reviewer only sees material already flagged as appropriate for release.
Redaction rounds out the process, with the ability to apply bulk redactions based on keyword lists (specific projects, individuals, IP addresses, credit card numbers) alongside manual redaction for anything unusual that turns up during review. Crucially, every redaction, every search, every classification decision is logged automatically. Nobody has to keep manual contemporaneous notes while working through it.
The numbers Nollag shared for what this looks like at scale are striking. A starting volume of over 100,000 collected documents can be brought down to roughly 60,000 after deduplication and thread intelligence, and further narrowed through document type triage and targeted search until the substantive review list sits at somewhere around 12,000 documents. That’s the difference between a task that feels endless and one that has a visible finish line.
The Real Value: A Finish Line You Can Trust
A recurring phrase throughout the session was “the finish line.” Nollag returned to it repeatedly, and it’s arguably the most important idea in the whole webinar. When an organization doesn’t trust its own search process, there is no finish line. Every response feels provisional. Every complaint to the DPC feels like a threat rather than a legitimate check. Teams end up re-checking the same data five or six times, second-guessing themselves, and dragging a single request out for months.
A defensible, fully documented process changes that dynamic entirely. When you can say to a data subject, “here is what we searched, here is what we found, here is what we redacted and why,” and back all of it with an audit trail, the DPC stops being an adversary and becomes what it’s actually meant to be: a body you can confidently refer a dissatisfied requester to, because you know your process will hold up to scrutiny. Mark made the point that showing a regulator you’ve taken the process seriously, with proper documentation and defensible methodology, tends to earn considerably more goodwill than a response that looks rushed or defensive.
There’s also a psychological dimension worth mentioning, one that both speakers touched on with a bit of dry humor. A meaningful number of DSARs, particularly the adversarial ones, are submitted more to cause friction than out of genuine interest in the data. Nollag noted that organizations have shared complete, thorough DSAR responses with individuals only to find the files were never even opened. A confident, complete, well-documented response tends to deflate that kind of request rather than fuel it further.
Practical Takeaways
The webinar closed with three clear points worth repeating here.
First, DSAR complaints continue to rise and the requests themselves are becoming more complex, partly because AI tools are making it easier for individuals to draft detailed, wide-ranging requests covering metadata and internal communications. The advice here was reassuring: you don’t need to answer every individual sub-question line by line. The fundamental obligation doesn’t change. Search where you reasonably believe the data to be, document that decision, and don’t let an elaborately worded request pull you into scope creep.
Second, tooling is the actual bottleneck for most organizations. License costs, missed data, duplicate-inflated volumes, and one-shot searches that can’t be meaningfully refined all combine to make a Microsoft-only DSAR process slow, expensive, and hard to defend at scale.
Third, a better process already exists and follows five repeatable steps: deduplication, thread intelligence, type triage, iterative AI-assisted search, and list-driven redaction. That’s a process with a defined cycle, predictable timelines, and a genuine end point, rather than an open-ended slog.
Watch the Full Recording
This summary only scratches the surface of what was covered, including a detailed Q&A section addressing questions on data sharing agreements, on-premise versus cloud deployment options, and how DSAR tooling connects to broader records management and data classification work. If you’re responsible for handling subject access requests in your organization, whether you’re dealing with a handful a year or several hundred, it’s worth watching the full session.
The recording covers the complete walkthrough of the platform, live audience poll results, and the full discussion between Nollag and Mark on where DSAR practice is heading next, including some interesting commentary on AI-generated data tagging under emerging EU requirements. Watch it below, and if you’d like to talk through what a defensible DSAR process could look like for your organization specifically, Complete GRC and Nuix are both happy to follow up directly.
