GDPR Compliance and Payments

We at Spreedly, like everyone else who handles sensitive data and is invested in security, recently went through our preparation for GDPR. You know GDPR I'm sure - it's the reason why we've been spammed incessantly by companies who suddenly care about your rights and consent on all of your data they've harvested.

As Spreedly's Security Manager, I like to imagine it might be interesting to a silent minority of you how we handled various aspects of our GDPR preparations (that feels like the appropriate number of qualifiers for this). With that in mind, let's dive in!

How does Spreedly feel about GDPR?

Security and compliance are nothing new to Spreedly - as a fintech startup we learned early on that keeping the regulation in mind was immensely more preferable (and efficient) versus trying to fit it in after the fact, so we made security a central part of our company culture. We are secure because it's the capital "R" Right thing to be - it also happens to be immensely convenient that being secure is fundamental to our company. What this means is that when we are looking at various compliance frameworks what we are trying to determine is not just the letter of what they are asking, but what is the intent obfuscated behind the regulation. This intent is almost always being secure, but risks being nebulous and bogged down by regulating to the masses - or by being defined by lawmakers who don't understand the current ecosystem.

Predictably, this was apparent in our approach to GDPR. Looking from a security perspective we were already 90% there: the main change we had to deal with was updating our understanding of sensitive data from the PCI definition to the GDPR definition. For PCI sensitive data means Cardholder Data - like the Personal Account Number (PAN), CVV or other financial information whereas, for GDPR, sensitive data means any collection of personal data that could result in an individual being identified - first name, last name, all the addresses (email, home, and IP), zip, and any additional unique online identifiers. The other security stipulations of GDPR were more broad and already caught in our existing security model (least access, routine training, encryption etc.).

The remaining 10% boiled down to spreading awareness internally, consulting on what should be included in our Data Processing Agreement, tracking down data flows and subprocessors, and documenting out what happens when we get a data subject access request. For this post let's look closer at the considerations that went into how we decided to handle these access requests.

What to do about Data Subject Access Requests

As we all know, GDPR empowers the original data subjects (those from the EU at least) with a variety of data subject rights. Faced with these suddenly legally empowered users, many companies created self service portals for their users, or controllers, to use for the inevitable deluge of data subject requests. While that is certainly a valid and laudable approach, we instead opted to handle these on a case by case basis through our existing customer support channels.

The justification for this approach was simply that we are pessimistic (or optimistic depending on your point of view) that there will be a number of requests to justify a very large investment in new development. The meat of this rationale is that for the vast majority of our business we are a subprocessor in payment processing and folks are generally aware of, and onboard with, their financial information being used to process their transactions. Secondly, according to the regulation, we would have between 1 and 3 months to return any requested data (in the spirit of transparency we would actually have less, the controller has that time requirement from when they receive the request) which is enough time to us to run through that manually, and to assess if that is an unreasonable burden. Finally, our controllers already have a large amount of visibility and control over any of their data that we process. This is achieved through our well documented API, and after a quick review we realized all the base functionality for these requests already existed - though it was currently targeting PAN data exclusively. With this in mind, rather than assume this would be a commonplace customer request, we reasoned it might be an infrequent request that can be handled periodically.

Regardless of a self service or manual solution, we still needed to sort out the step-by-step of how we were going to handle these requests: In the event that a request comes through, our support would work with the controller to achieve that request through our already existing API - turns out the payment_method_token has all the relevant information attached to it. This wouldn't get everything - any associated data that lives with one of our subprocessors would have to be tracked down manually, and we don't have a specific publicly accessible API command to scrub all GDPR data (ours are still focused on PCI data) so we would have to run those on our end. Not perfect, but the right approach! Then we thought of the fringe case for our expected fringe case:

Handling Data Access Requests in bulk

What happens when a controller/customer has to redact a bulk set of data? We have customers who function as intermediaries (think a marketplace or platform) so it's easy to imagine them being put in the situation where they have a customer churn and therefore have to redact all the associated data from their subprocessors. At face value this was a daunting proposition.

After some reflection the obvious solution was just use the API.

Most of the customers of this nature fall into one of two buckets for how they handle the multiple merchants in their database: they might have policies in place so that each merchant ID is its own gateway token, or simply track their internal merchant via their merchant ID (or some other unique identifier). Both of these buckets assume that the customer maintains a database of their transactions on their end as well (which follows the broadly established best practice). Either of these approaches would enable a customer to use their own commands to track down what data would need to be redacted (therefore limiting their exposure to our very reasonable API fees) before using our API to redact that data. All in all, a pretty elegant ad hoc solution to an unlikely scenario.

What's next?

Now that GDPR is live most companies, including Spreedly, will be watching with interest as actual legislative infrastructure is built out around GDPR (as of the writing of this article only a handful of the European member states have the appropriate laws in place to fully enforce GDPR), we will also be keeping an eye on legal cases that have already been filed with other companies, and of course, keeping an eye out for any data subject requests from our own controllers.

‍

Download the PCI Compliance eBook Below