The Devil’s in the DSARs – How to operationalize your response

The Devil’s in the DSARs – How to operationalize your response

By: Tom Preece

Executive Summary

  • Do not believe that you need to spend enormous amounts of money on technology to achieve compliance 
  • Acknowledge that risk analysis is key to determine where investments are truly needed 
  • Metric tracking from the start is the most essential data for better risk analysis and process improvement 
  • Understand the rights you are afforded as a company to defend against weaponized requests 
  • Consider every DSAR request fulfillment as an audit of your response strategy 

The Devil’s in the DSARs

You do not have to look far to understand the basic steps required for Data Subject Access Request (“DSAR”) response. One of the more notoriously burdensome processes to come out of the GDPR is that any employee or client (current or past) can, at will, instruct you to find and act upon all of his/her Personal Data within the control of your company, no matter where it may exist. A basic DSAR response workflow will look something like this:

DSAR response workflow
DSAR Response Workflow

However, truly operationalizing the DSAR response process is far more complicated, not only in terms of getting started, but also in terms of improving the process over time to ensure it can grow alongside your business. 

This article provides guidelines on how to evaluate, improve, and manage risk associated with responding to DSARs.

Technology

A lot of technology has been developed specifically to enable GDPR compliance – especially DSAR fulfillment – and many technologies have been re-branded and retooled to provide GPDR compliance. As a buyer, you should understand that there is almost always a license-free technology alternative that can help perform any of the six steps listed above, and the decision to use a subscription technology should take that option into account. In other words, do not believe that you need to spend enormous amounts of money to achieve compliance. Sometimes, the right tool for the job is a technology you already have. 

For example, it is common for organizations to facilitate requests through an email distribution list, where a data subject emails a request that is manually routed to a fulfillment representative. This workflow might be sufficient enablement for your organization, and since it does not require any more technology investment, it may be the right choice for a budget-conscious organization. However, there are downsides to this approach: 

  • Email requests are known to duplicate Personal Data inadvertently. Communications between the data subject and responder regarding the request can generate Personal Data on business systems. Sometimes, data points are not collected during the normal course of a given request transaction. Therefore, they are not accounted for by an organizational data inventory/data map. Furthermore, these data points are often populated in several different mailboxes in CC, and those recipients may forward the emails containing Personal Data to others internally. It’s important to track all messages created during the response process. A manual means of tracking is error-prone and can cause expensive problems. 
  • While email is a good technology for facilitating communication at scale, it will not enable scalability for any other aspect of your response. In other words, if you receive 60% more requests one week than normal, your email application will have no problem keeping up, but the nature of manually responding to them all via email may not be as scalable. 

The next level of technology investment is typically an online form, sometimes even an online portal, where data subjects sign in before submitting a request. This type of workflow is system-driven and there are low-cost options for adding web pages or even basic workflow before reaching expensive, high-performance GDPRspecific tools. 

Using a risk-based approach takes additional work, but provides excellent targeting for limited budgets. In other words, consider what could go wrong at every step of your response workflow and the likelihood of that risk coming to fruition. Try to quantify how damaging the risk would be. Obviously, high impact risks that are likely to occur should be a top priority for considering a technology investment, or at least process improvement. 

However, low impact risks that manifest frequently might be a good place to consider bolstering your scalability. For example, searching for relevant information may consistently take longer for every single request than you predict, and even though you do not think there is a big risk in missing a deadline now, if you suddenly get a surge in requests, there is a higher risk of missing deadlines frequently. You may want to consider an index and or search technology for your IT ecosystem. 

Alternatively, an event that is less likely to happen, but if it does, could have severe consequences may be considered an essential risk to mitigate. For instance, you may not get many fraudulent requests, but the reputational and financial impact of disclosing personal information of one of your clients to a third party could be disastrous. With this in mind, you could consider investing in third-party authentication technology. 

Cost per Response 

A key to operationalizing any business requirement is establishing and tracking key metrics. If organizations can handle a low volume of requests with even the most perfunctory process, they often make the mistake of not tracking specific cost or performance metrics, thinking those metrics are only appropriate to collect within the context of a more mature function. If nothing else, your Cost per Response should absolutely be tracked from the beginning, in a repeatable, consistent matter. 

Although it may feel like unnecessary work, this is the most important metric to track for a few reasons: 

  • When considering changes to either your DSAR response workflow, the way you approach Article 30 record keeping requirements, or the impact a new business application might have on your workflow, you need an established baseline for the average cost per response. Only then will you realistically be able to assess if the change was positive or negative. 
  • If you know you and your team want a better technology to help with your response process, it is essential to justify the cost. If you demonstrate that for the last six months the average response cost was $X, and by introducing a new authentication service you could reduce it to $Y, then requests to your IT procurement are more of a formality. Furthermore, it might help you minimize or target those investments. For instance, you may discover that the average request cost coming from customers in France is two times higher than from any other location because France is the oldest office, and it has two times as many records to search across. If you install a search technology for just them, you have limited the investment cost while still maximizing the benefit. 
  • It gives you essential data in refusing a weaponized request (see below) in a defensible way. 

When getting started, thinking of every possible cost involved is not necessary. Cost tracking can evolve as you experience more requests. Common costs to consider: 

Of course, there are many other metrics you can consider tracking: 

  • The average turnaround time for each request 
  • Calculate your capacity, or how many requests you can likely handle in each period with your available resources 
  • The average number of back-and-forth communications to settle scope before searching for information 
  • How many requests in each period you could realistically scale up to by adding additional resources 
  • Qualitative metrics, such as the data subjects satisfaction with your fulfillment, or even the morale of your employees responsible for fulfilling requests 

Recognize the Opportunity 

When employees begin to fulfill DSARs, they will start to interact with several different manifestations of your GDPR compliance program. In other words, they are getting firsthand experience with how your compliance structure is practiced versus how it’s designed on paper. If an employee checks the data inventory and/or data map to find a certain type of information, and he discovers it is unavailable, he may reach out to others to locate it. Likewise, if employees find much more data than expected, there may be a weakness in your retention and deletion functionality. If the employeeare only thinking about getting the DSAR resolved as quickly as possible, they will have no incentive to record irregularities and ensure an underlying problem is resolved. 

Once you understand the potential intelligence your employees are exposed to when fulfilling these requests, you can start to think of every DSAR as an audit and train your employees to think about process improvement while conducting their work. But, if you do not have an easy way to capture and report on that feedback, you are going to miss out on the opportunity to improve. 

Weaponized Requests

Many organizations have already experienced what you might call a weaponized version of a DSAR. For example, fraudsters are eager to take advantage of poor authentication protocols in accessing personal data about third parties. One black hat researcher sent out 150 DSARs to different companies posing as his fiancée and received responses from about three-quarters of them. Of the 83 that confirmed possessing personal data about her, around a quarter of them disclosed the personal data to the researcher with little to no verification of the purported requestor. Take extreme care when it comes to authentication because an easier, cheaper authentication method that does not work will end up costing you a lot more in the end. 

Another type of request could come from a disgruntled employee or even an ex-client. For instance, you might experience an ex-employee requesting every single email that contains a copy of his or her name. Although the requestor has a right to his or her data, you also have the right as an organization to deny unreasonable requests. From Article 12(5): 

Where requests from a data subject are manifestly unfounded or excessive, in particular because of their repetitive character, the controller may either:
(a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or
(b) refuse to act on the request.
The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.

You will need to demonstrate the burden of the request in order to receive protection under the GDPR. An appropriate first step could be to request that the employee narrow his or her request. If the requestor refuses to do so, there is a good chance that the request is meant to burden you. If you have been tracking your Cost per Response for normal DSARs, you have a meaningful data point to use in your favor: for example, “given the scope of your request and in comparison with previous requests, we project the cost to be $X to search, cull, and redact the requested information.” Pair those data points with a second request to reduce the scope; if the requestor still refuses, not only do you have reasonable grounds for refusing to respond, you also have excellent documentation to provide to a DPA if audited. 

DSAR Process Improvement

Do not assume making the response process more efficient requires more technology. If you can identify a particularly burdensome stage in response fulfillment, the answer may actually be process improvement either on that stage or even upstream in the response workflow. 

For instance, if the data subject is submitting his/her request in plain language through an online form, a lot of work must be done by the responding employee to fully comprehend what the subject is looking for, compare it to the data inventory, and then initiate search across the corresponding data sources to located relevant information. Once a DSAR is fulfilled, there may be push back from the data subject doubting the response was complete. It is easy for the scope of a request to be skewed when trying to match up plain language requests to an organized classification scheme with a very specific taxonomy. 

Instead, consider giving the data subject a menu of personal data types to request in the online form. In other words, instead of a free text box, you could educate the data subject on the possible forms of personal data you might have using dropdown or check box menu items. Not only is a structured form more user-friendly for data subjects, but it also ensures the entire process is more scalable because the scoping stage of responses is now partially addressed by the data subject itself. 

Preparation

Of course, a major factor in the successful operationalization of DSAR response is what happens before you even receive the request. The GDPR is explicit in retention and destruction requirements, and enacting those guidelines will help ensure that all and only truly responsive information is recalled when searching for responsive dataArticle 30 dictates record-keeping for data processing, and those records serve as a key reference for directing responding employees where to look. Taking a closer look at best practices around these areas will go a long way to ensuring your DSAR response process is efficient and less of a headache for everyone involved. 

Conclusion

In the end, the most challenging aspect of designing an effective DSAR response is resource availability. It is a new, complicated, and highly demanding ongoing function of your business that never existed before, and one that will never produce revenue for you, only cost avoidance. That’s why it’s important to take a risk-based and measured approach to building out your capabilities, with a focus on gathering data whenever you can to make sure your future decisions are well informed and worthwhile.

Rational Governance can help. If you want to get a better handle on what data you have, enable defensible deletion as an automated, ongoing business function, and superpower your team’s ability to search across unstructured data, please reach out today to see if we are a good fit for your needs.  


Tom Preece

About The Author

Tom Preece

Director of Pre-Sales Consultancy

Tom Preece works directly with clients, partners, internal Product Development and Marketing to improve, sell, and deliver Rational Enterprise technologies. He converses daily with executive- and director-level practitioners in Legal, Compliance, InfoSec, Privacy, and KM departments to better understand their problems and relate the multi-layered value that in-place supervised machine learning technology can provide.