GDPR: Less Than One Month Out, the Top 3 Struggles
GDPR: Less Than One Month Out, the Top 3 Struggles
With GDPR set to land in a matter of weeks, let's take a look at three common themes surrounding organizations' concerns when it comes to getting compliant.
Join the DZone community and get the full member experience.Join For Free
Protect your applications against today's increasingly sophisticated threat landscape.
I recently shared some thoughts on looking back at the original objectives of the GDPR, to frame future implementation discussions. But, as we are now less than a month away from GDPR D-day, I thought it would be good to look at the present and share the top 3 struggles I have identified, based on conversations with customers and partners.
Most Asked Questions (and Answers)
May 25 won't be a replay of Y2K. In an earlier post, I've used Winston Churchill's words to highlight what I believe the main difference is: May 25 is "not the end, not even the beginning of the end, but the end of the beginning." On January 1st, 2000, we all breathed a collective Y2K sigh of relief.
Instead of a collective sigh, May 25 might create more of a collective grunt. Most privacy professionals know that although a lot of work has been done in the run-up to D-day, GDPR compliance will require a constant focus. It is a journey, not a final destination. Those organizations that treat May 25 as the endpoint of their compliance drive, will be proven wrong.
Another distinction between organizations will be their levels of ambition. Some organizations will look at GDPR as a mere checklist approach, I call it the "lawyer" approach (with all due respect to the lawyers amongst you, including myself). Legal compliance is core, but an organization's ambition should aim to go beyond and create a true cultural change. I truly believe that these privacy leaders ultimately will be rewarded in the market, banking on what I call a "trust dividend", reaping the benefits of constant investments in this space.
Even though there is a broad spectrum amongst organizations around GDPR compliance, there are also some common themes and questions. In my role as CA Technologies Chief Privacy Strategist, I have had the opportunity to discuss GDPR with organizations, both public and private. One way to look at the range of questions and struggles they are facing is through the lens of the data lifecycle; the collection, management, and deletion of data within an organization. Here are my top 3 of GDPR struggles.
1. Collection: Answering the 3 Ws: What, Why, Where?
Organizations need to understand how personal data is being created and collected: what different data sets are they collecting, for which purposes and how are they coming into their organizations. The discussion on legal grounds to collect data has kept many organizations very busy.
A big part of the answer is to create clear procedures and policies around data collection, and communicate them internally as well as externally. These are not easy decisions as they might conflict with business requirements. But as companies take these decisions, documenting the reasoning could go a long way towards accountability.
And the obvious: think before you begin. The best way to reduce risk is to avoid personal data collection where not needed, or where alternatives exist. One example: during testing stages, testers love to use real life (personal) data. This, however, means that personal data potentially finds its way into other databases. You could instead reduce risk by using masked or synthetic data in test environments instead of collecting data for these purposes. This brings us to the second point, once data is inside of your organization, how do you manage its life?
2. Managing Data: Preparing for Data Breaches
Once the decision is made to collect personal data and it makes its way into your organization, keeping track of where it resides and who has access to it is another challenge. Organizations need to invest in tools to map data streams, discover personal data in their systems and protect/track its access.
A big driver for these organizational discussions has been the GDPR focus on data breaches. In conversations with customers, I still get many questions around the actual implementations; timelines for reporting, who to report to, what about the data processor obligations, and the interplay between security and data breaches.
Let us start with the obvious: Prevention is better than the cure, so invest and prepare. This means investing in security measures to ensure that only the right people have access to the data, and that this access is limited to only the data necessary to perform their roles. You should always prepare for the worst. Draw up remediation and response plans, train your people to identify signs of a breach and to report as soon as they expect something has gone wrong.
But if something does go wrong, under the GDPR, you may have to report to the appropriate authorities within 72 hours. In some cases, you may have to report to the users directly. Simple, right? Well, as most practitioners probably know, the real world is a bit more complex than that. I wrote a recent blog post outlining some of the key aspects and main points.
3. Deletion of Data: Do We Have the Right to Forget About It?
The right to be forgotten and to a larger extent, data subjects' rights in general are also challenging issues for organizations. That doesn't mean that organizations can ignore and forget about it. The solution links to the earlier points: reduce the risk by avoiding data collection where at all possible, and the need to keep track of it. But another challenge emerges; what could organizations do if they get such requests for data and how do they authenticate users to avoid sharing personal data with people that pretend to be somebody else? Should they do it the old-fashioned way via copies of identity cards? Do they need to request additional personal data to use for verification (counterintuitive to the GDPR objectives)? There is no simple answer but I do believe technology will need to play a crucial role in authenticating requests and protect the data while doing so.
Published at DZone with permission of Christoph Luykx , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.