GDPR – Compliance Guru

Hey Guru!

I have heard a lot about GDPR recently, but I am not terribly familiar with it. I already break my back to stay in compliance with FFIEC guidance. Do I have anything more to worry about here?

GDPR has certainly been in the news for the past few months as implementation was required as of 5/25, but interpretations have varied as to how this will influence US-based entities with no real European presence. While it is still too early to know exactly how GDPR will be applied and enforced, the basic framework still leaves us with plenty to discuss.

The Basics

The General Data Protection Regulation was designed by the European Union (EU) member nations to create a uniform standard of consumer data privacy protection for all companies that do business in the EU. Think of this as GLBA with a few added features.

In the context of GDPR, protected parties (consumers) are called “data subjects”, any party in control of data (like a financial institution) is called a “controller,” and any entity that interacts with that data on behalf of the controller (like a technology service providers) is referred to as a “processor.” The regulation concerns itself with the privacy of EU citizen data. In this respect, it has the identical goal of GLBA.

The Scope

Naturally, GDPR applies to entities physically located within the EU member countries, but the regulation could, under certain circumstances, reach “across the pond”. Included are organizations based outside the EU that provide goods/services, or track the behavior of, data subjects within the EU.

In theory this COULD include your institution, but it’s a bit of a long shot. It really boils down to this: do you have any EU citizens, or dual US/EU citizens, on your list of customers/members? If the answer is “no”, then in all likelihood you can rest easy unless you are actively marketing to EU citizens.

Notable Rules

Financial institutions that are required to comply with GDPR have a head start. As I mentioned, many of the basic privacy and security principles of GLBA translate to GDPR; however, there are a few key areas where GDPR takes things a step further:

Right to be forgotten/Right to Erasure – EU citizens covered by GDPR have a right to request that any and all personal data you have on them be corrected (if inaccurate), or deleted entirely. A key note here is that this is only required if the individual makes such a request, and even then, the institution would have 30 days to respond. Since Core processors are likely to be your single largest data store of customer information, you may want to check with them on their GDPR compliance efforts. Other places this type of data might be located is email, including hosted email services (such as Exchange Online). Responding to a Right to Erasure request may be a bit tricky in a cloud environment, as email cloud companies would need to work with their 3rd party vendors to find and purge the email, as well as all backups and archives.
72 hour breach notification – If your institution experiences a breach, you’ll have 72 hours from that point to notify the supervisory authority in the member state in which your customer/member resides. GLBA does not have specific timeframes on notification actions, specifying instead that “…a financial institution should provide a notice to its customers whenever it becomes aware of an incident of unauthorized access to customer information and, at the conclusion of a reasonable investigation, determines that misuse of the information has occurred or it is reasonably possible that misuse will occur.”
Explicit Opt In requirements – This is where GDPR really deviates from GLBA. Essentially, EU citizens must both opt in to what information will be collected about them, and must agree to every way in which that data is used prior to those actions taking place. GLBA regulations are generally more reactive here, they allow institutions to default to an opt-in position, requiring notification to opt-out.
Contracts – Similar to GLBA, contracts with third-parties transmitting, processing or storing EU citizen data should spell out how the exchange and use of data will work with data processors, and for what, exactly, each party is responsible. In practice, this would just become a deeper dive during due diligence/on-going monitoring of your Technology Service Providers.

Enforcement

Let’s put things back in perspective. While GDPR provides for rather severe penalties for non-compliance, there is still the matter of enforcement. Even if EU regulators wanted to take enforcement action against a US financial institution – would they, and more importantly, could they?

First of all, the EU has made it clear they’re only going after the worst and highest profile abusers of the regulations. Since most US-based financial institutions do not have any direct business presence within the EU, and few if any EU citizens as customers/members, they just aren’t likely to be a target for EU regulators.

Second, it is very unclear how a US institution could even be sanctioned or penalized by EU supervisory agencies, even if the institution has EU citizens as customers/members and has run afoul of the regulations. Worst case is you’ll have to terminate your business relationship with the EU citizen.

In the meantime, we’re definitely going to keep a close watch on how (and if) the US financial regulators react to this, and act accordingly. Up to now they have been completely silent on this matter, which speaks volumes to me. So until then, I think you can rest easy, or at least easier!