Data Subject Requests (DSARs)

A recap of the Pyxos masterclass with Richard Chudzynsky and Joe Corina.

In a market still new to data subject rights, the organizations that handle them well are the ones that prepared before the first request arrived. That was the practical heart of this masterclass on Data Subject Access Requests, led by Richard Chudzynsky of Konexo (Eversheds Sutherland) and Joe Corina, Head of Data Privacy Operations at Teya. Their framing, repeated more than once: failing to plan is planning to fail.

DSARs are difficult precisely because they bring an outside request into contact with data scattered across the systems, teams, and departments of an organization, and they do it on a fixed clock. The session was candid that the Kingdom is not yet accustomed to these requests, which makes the recognition problem the first real risk. A request does not arrive labelled. It comes through customer service, an HR inbox, a phone call, or an offhand email, and if a frontline team does not recognize it as a rights request, the response clock is already running before anyone in privacy knows it exists.

That clock was a point of emphasis. The thirty-day window begins when the organization receives the request, not when the privacy team becomes aware of it, which is why training the front line to spot and escalate a DSAR matters as much as the fulfilment process behind it. The presenters walked through the lifecycle from intake and identity verification to search, review, and response, with the recurring caution that identity verification must be proportionate: asking for more identification than the sensitivity warrants is itself a concern.

Two operational realities drew useful discussion. First, broad requests, the familiar give me all my data, are better narrowed early through a conversation with the requester than answered with an indiscriminate data dump. Second, not every request can or should be fulfilled in full. The PDPL allows a request to be limited or refused on narrow grounds, where it is unjustifiably repetitive, requires extraordinary effort, would compromise the rights of others, or cannot be verified, but the presenters were clear that partial fulfilment is usually the better path than outright refusal, and any refusal has to be reasoned and communicated.

Redaction came up as the safeguard organizations most often underestimate. A response that discloses one person's data while exposing a third party's has solved one problem by creating another, so the review step has to strip out third-party personal data and anything else legally protected before anything goes out. Deletion requests carry a parallel complication: they have to be weighed against statutory retention obligations, which frequently produces partial rather than complete erasure.

The thread that tied it together was documentation. Corina and Chudzynsky were emphatic that the last thing you want is to be reconstructing your rationale and your process when a regulator asks you to prove you followed the law. Every interpretation, search, and disclosure decision should be recorded as you go, supported by an intake log and a repeatable workflow. The detailed lifecycle and the full toolkit are best taken from the recording and the takeaways.

The session closed where it began: this is manageable, but only if the workflow, the training, and the records exist before the requests start arriving in volume, because events such as a breach can drive a sudden spike in rights requests, and a process improvised under that pressure rarely holds.