I was a couple weeks into my new job at Braze back in March when a data subject request email landed in our privacy inbox. I’d been off on maternity for a few months, far from any privacy-related matters, and my first reaction was, “How, exciting—GDPR in action!”

At Braze, we’ve had the EU’s General Data Protection Regulation (GDPR) on the brain practically since it was passed back in May 2016. If you’re not familiar with it, GDPR creates stricter rules regarding companies and other organizations’ use of personal data of EU data subjects—and gives those subjects more control over their personal data and how it’s collected and used worldwide. (You can get more details here.) And as part of that, EU data subjects gained the ability to request to have their personal data deleted under certain circumstances.

When that first data subject request arrived at Braze, I was studying for my Certified Information Privacy Professional/Europe (CIPP/E) certification, and I was very keen to put in practice what I was learning. At the time, we were still a few months away from full enforcement of GDPR, and a formal process for handling these kinds of data subject request was still on our to-do list—so I took the lead in creating a data subject request process for Braze. After weeks of collaboration with our Marketing and Operations teams, our Data Subject Access Request (DSAR) Form came to be.

Full enforcement of GDPR came into effect on Friday, May 25, 2018, and when it did, a few more requests trickled into our system. (It worked! We were thrilled!) But once our excitement over the process passed, it was time for us to actually address the requests. That’s the rub: when you outline a process like this, you try to think of every possible situation, but the reality is always different. As we worked through some challenges with those requests, I spent a lot of time searching for guidance—and actually found little that applied to the issues we were facing. That inspired me to share our learnings, and so this article was born!

Data Subject Identity Verification: The Struggle is Real

Let’s start by looking at the challenges we faced regarding the verification of the data subject’s identity.

In order to be sure that the individual asking to access their data (or to have that data deleted) is the person that data refers to, we have to have a way to verify that they are who they say they are. However, when we built out this step in our DSAR process, we weren’t keen to ask data subjects for a copy of their ID—both because we’d then have to process additional personal data and because it seemed counterintuitive, especially for deletion requests.

As a data controller, Braze only processes a small amount of personal data beyond the data we hold about our own employees. Mainly, we process data for marketing purposes, which involves mostly names and email addresses. There’s not much to go on there to verify someone’s ID, so we decided to ask for individuals filing a DSAR to send a copy of their ID from the email address they claimed was theirs (to show that they had access to it). Hopefully, they’re the rightful owner of that inbox, but the reality is that there’s not much else we can do to check this.

We felt that it made sense to retain the copy of people’s ID only while we were processing the DSAR and decided we’d delete promptly it after completing each request. We expected people to have qualms about sharing a copy of their ID, but they’ve usually provided it almost immediately—maybe because we assured them that we would delete it once their request was dealt with. But while it’s all well and good to decide to promptly delete the copy of each individual’s ID, the permanent deletion of an email proved to be a bit more challenging than you might think.

Data Deletion: It’s a Journey

When a new DSAR is created in our system, myself and the other members of the Braze Privacy Team are alerted by an email sent to a shared inbox. Upon the completion of our first DSAR, we asked Privacy Team members to delete any emails they’ve received containing the data subject’s ID. But while everybody complied, deleting the messages and then emptying their email trash folder, we discovered that the email in question was still being retained by our email provider for a period of time.

After a bit more digging, we found a way to set up a specific data retention period for our shared Privacy Team inbox. Our joy was short-lived, however: we quickly realized that this fix would delete all emails from that inbox after that period, which was a problem because we needed to keep track of other emails exchanged with the data subject. Worse, this didn’t solve the deletion issue associated with our private inboxes, since we receive a copy of all emails that land in the shared one.

After a bit more head scratching, we created yet another inbox—to be used solely to receive the data subject’s email containing the ID copy—and applied the short data retention period to it. We turned off that inbox’s email alert so that copies of the emails weren’t sent to our personal inboxes, and just check the shared inbox manually when we’re waiting for an ID copy to come through. That way, once the DSAR is fully dealt with, we can just delete the email containing the ID from that inbox, and the email will be automatically and permanently deleted shortly after from our email providers servers via the data retention rule.

Data deletion, it turns out, is a journey…