Q&A on Locating and Managing EU Personal Data for GDPR Compliance
Locating and Managing EU Personal Data for GDPR Compliance
Spirion recently hosted a live webcast discussion on the topic of “Locating and Managing EU Personal Data for GDPR,” featuring a panel of security experts, comprised of: Colin Anderson, global CISO of Levi Strauss & Co.; Todd Feinman, founder and CEO of Spirion; Scott Giordano, privacy attorney and director at Robert Half Legal; and, Justin Suissa, principal at infoedge.
In this webinar, the panel dives into a critical step on the roadmap to GDPR compliance – identifying, discovering, and inventorying your PII data- and, discuss their experiences with the following scenarios.
- Am I considering all of the right data types, elements, and scenarios for the scope of my program?17
- What methodologies and techniques are available to handle the critical data discovery and inventory step?
- How should I fit this effort into other enterprise compliance efforts?
- Once discovery and inventory are underway, where do I go from here?
Watch the webinar replay here.
The panelists responses to unanswered questions asked by webinar participants are below. We thought the community at-large would be interested in reading these responses, as well.
1. Isn’t the DPIA an audit in GDPR?
If the data privacy impact assessment (DPIA) is conducted retrospectively, it could be considered an audit; conducted prospectively, it is an assessment.
2. In response to the comment: Matching GDPR and national requirements for data retention vs. right to be forgotten. How do you practically resolve the differences between other regulations (e.g. national) requiring data retention and GDPR’s right to be forgotten? Well, too many to discuss, but why not start with Germany and Switzerland.
The “right to be forgotten” is not an absolute; it is subject to reasonable limits, some of which are cited within the GDPR. As of this writing, data retention mandates in the EU have been substantially limited.
That being said, a global view of rules and restrictions needs to be gathered and understood, for data handling as much as for any other cross-border activity. Your legal team can help council where legal regimes may conflict, and defined risk tolerance can help dictate how conservative one is. Further, an industry we need to bubble up to regulators when there is conflict and push for better integration an interpretation.
3. If EU citizens data processed in the US, will that Data be subjected to GDPR regulations “right to be forgotten”?
Yes. The GDPR applies to EU data subjects’ personal data, regardless of where it is being processed.
4. If the request is made before a data retention schedule is reached for the data subject records , do we still have to be compliant to the right to be forgotten?
5. If my organization is compliant with ISO/IEC 27001, NIST 800-53; 27000 0r SSAE-16 what do I have to do differently?
Compliance with those standards only addresses the information security requirements of the GDPR – Art. 32. There are still 98 additional Articles, about 50 of which require some action on the part of data controllers or processors. Further, your risk from regulation sources (in this case GDPR) may impact your controls landscape and need to be considered as part of the risk assessment requirements in those frameworks.
6. What happens post-deadline?
We looked into our crystal ball and….turns out the crystal ball isn’t working right now. The truth is we don’t know, though we can use precedent from other regulatory standards to offer a clue. That clue is that it will be a bit of a learning curve for both companies and regulators. Regulators will likely tighten unclear definitions and provide additional guidance, and businesses which put meaningful due diligence into meeting the regulation will be ok; those that try to skirt the intent may be made examples of. We also know the EU takes privacy very seriously, and are meaning to show they are strong on this point. For one, the penalty provisions are high. Thus, we expect them to audit strongly out of the gate. While they indeed might go after some key companies that they want to reign in quickly, anyone could be a target, especially if an EU citizen raises a flag or complains. For individual companies, where do you want to be when the regulators come knocking; are you prepared for the consequence of not being in compliance?
7. What kind of regulatory audits would be conducted to validate the compliance to GDPR?
The Supervisory Authority (SA) is granted vast legal powers under GDPR, both to investigate (i.e., assess/audit) as well as pass down corrective and punitive actions. How each SA will do this is unclear, and likely, especially at first, it may vary from SA to SA. We have not yet seen any SA audit plans (if you have please share!). What we tell our clients is to leverage internal audit to help design a work program based on the regulation and incorporate it into your controls testing. As with all good compliance practices, collect evidence and make it as simple yet comprehensive for the assessor to review your people, process, and technology for alignment to the requirements.
8. Not even EU based lines of business understand this regulation and therefore haven’t been fully supportive of corporate (“US”) based compliance.
Yes this can be a challenge, from a cultural prospective. A push should be made to garner executive support (CISO, Legal, HR, etc), and have this evaluated as part of Enterprise Risk or Enterprise Compliance processes. The company should make risk-based decisions on what the impacts might be, the potential penalties and corrective actions would almost certainly impact key business processes and finance. As mentioned, it doesn’t matter where you are based, it matters what data you have.
9. How do you recommend overcoming these objections? That definition didn’t address AD credentials. So, are the panelists “sure” of the definition?
AD credentials are covered under Recital 30’s definition of on-line identifiers, no question about it.
10. Doesn’t that impede fraud investigations?
No, Recital 47 states, “The processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned.”
11. Purging of the customer’s data… like the video statement. Is it in scope? Couldn’t someone use that to hide their malicious activities? If someone say used a stolen ID information, and then followed up with a request to purge the data, wouldn’t that hurt any investigation?
Yes, this is certainly a risk GDPR presents. As mentioned before, if the data is strictly necessary to prevent fraud, it can be held. Strictly is the key word here. A savvy criminal may take advantage of the loopholes here to cover their tracks, though at the same time they may also be exposing themselves. Data handling should also be considered as part of your Incident Response program.
12. Another question… My CIO and Legal think that it may take time before smaller companies are impacted or fined, that the bigger fish (Facebook, Google, etc.) will be targeted first and many court cases will help define the specific requirements. I see a lot of fault with this logic. Are many companies thinking this way?
Are many companies thinking this way? Yes. Are they right? Not entirely. Regulators will likely be intent on having the big boys in compliance, however anyone can get called onto the floor as penalties could result from end user complaints. Small and immature companies will likely get tangled up if they can’t respond to user requests, for example. Likewise, a few smaller companies may be called out quickly to show this applies to everyone. Time will tell…
13. Is the definition of sensitive data being understood clearly?
Yes. Article 9 defines sensitive personal data and that definition has been used for the past 20 years with the Data Protection Directive.
14. Is there any list of steps to be followed in order to comply with GDPR?
The response to this is a mouthful, and whole whitepapers can and have been written on aspects of this. It also heavily depends on the nature of your business, what you have in place already, what your strengths are, and the kind of funding you have available to attack the problem. We are planning to have several workshops to talk about just this topic, and invite you to attend. Further, we’d be happy to have a conversation with you and anyone else interested 1×1, in order to dive into your situation and provide some guidance. Please reach send an inquiry to firstname.lastname@example.org or visit the Spirion web site and submit your inquiry here.
15. If the existing privacy data with different retention requirements cannot be separated and very difficult to separate and apply controls, what to do?
Do you know the nature of your data? Where it is and what it contains? There are tools to help you do that as well as help safeguard it once you have it. This will go a long way to making this simpler. Further, you should consider the risk, and controls and processes required to administer those controls. Also know that you aren’t the only one in these scenarios, and reviewing the intent of the requirements and putting due diligence towards that may be sufficient. Focus on risk and objective.
16. Are there any frameworks, best practices to follow in order to comply with GDPR?
We discussed a few on the webinar, including automating data discovery and using a centralized data vault to manage your PII. For Art 32, there are several industry frameworks available including ISO 27001 and NIST 800-53. Which you use depends on the current control and regulatory landscape of your organization. There may be additional lessons that can be applied based on previous data protection and privacy initiatives that you can borrow from. Finally, attended webinars like these and speaking with peers goes a long way.
17. Are the accountabilities, responsibilities of data for each status (store, process, transmit etc) based on the who is being clear?
If you mean that it’s clear who is the identified or identifiable data subject, then yes.
Watch the webinar replay here.