18 September 2017
18 September 2017

So, what is GDPR and why should Database Administrators care?

You’ve no doubt heard at least something about the GDPR, the EU’s new privacy and Data Management law with its greatly increased maximum fines for non-compliance and tighter definitions for acceptable use of personal information.

If you’ve continued reading past paragraph one of any of the many articles, you’ll be aware that the law applies globally, to all organizations holding EU citizens’ data – it’s not bounded by geography or jurisdiction.

Many of the articles have emphasized the increased penalties, much to the chagrin of the UK’s Information Commissioner, Elizabeth Denham, who is charged with enforcing the law in the UK (and yes, it will apply after Brexit, assuming Brexit happens).

“Heavy fines for serious breaches reflect just how important
personal data is in a 21st century world. But we intend to use
those powers proportionately and judiciously.”

But this is all C-level chatter, surely?

Yes, the boss needs to know about increased risks from incorrect data handling, but what should a DBA do, other than wait for new edicts from on high? Especially when the data held by the IT department is actually a business asset and data governance is often the responsibility of multiple people or even departments.

If, like many DBAs, you’d rather spend your time applying your skills to optimizing your systems, tuning for performance and bang-per-buck (and minimizing the firefighting in between), why not just wait and see?

Well, there are a few reasons the smarter DBA should be preparing now and getting his or her estate in order, ahead of the May 2018 enforcement date.

Probably the biggest is that the new law requires ‘privacy by design and default’ throughout data handling.

Like most regulations, it’s open to interpretation, but regulators have been clear that data protection safeguards should be integrated into products and services from the earliest stage of development, with privacy always the default option.

But privacy of what, exactly? Not all data is private data.

You’ll need to do some thinking upfront about this because before GDPR even becomes law, you’ll be expected to have audited your data and identified the two categories of personal data that require special handling.

Two categories? Yes. Standard personal data includes details like names, addresses, cookie strings, and web surfing data. ‘Special’ personal data relates to data that is, literally, more personal like racial or ethnic origin as well as biometric and genetic data.

That said, now’s the time to ask three key questions.

  1. Where is your data? You’ll probably have more than one database, and you also need to remember legacy systems that are still in use, backups, and copies that might be used in development and testing.
  2. What exactly is your data which might be affected by the new law? You might want to take a broad brush approach, and categorize your CRM database as private, but how about web orders, purchase histories, audit logs? You and the business owners of the data (these might need to be assigned as well) are going to have to talk and agree how to classify all of the data you keep.
  3. Who is accessing your data? This is probably the most crucial part of the whole exercise. If you do make copies of databases for use in development and testing, for example, you’ll need to consider masking personal data. You’ll also need to think about data access requirements so that people only have permission to view, modify or delete personal data that is relevant to their job role, and for which appropriate consent has been obtained.

Now picture being unprepared when answering those questions for your organization. Many companies have problems of data sprawl and you won’t be alone in not being sure where all the data is, and who really needs access to it.

Is that the answer your CEO will expect? Or the new Data Protection Officer (oh yes, you might be getting a new colleague with statutory responsibilities to enforce GDPR compliance).

This isn’t all you need to prepare for, but it’s an important first step in ensuring you’re compliant with GDPR. So start the conversation, take the lead if you can, and you’ll protect yourself from impossible deadlines coming out of a ‘panic compliance’ project.

The future you will thank you for starting your GDPR journey now.

This is the first post in a series about GDPR. I’ll be covering different aspects of the new regulation that DBAs should be aware of to help you prepare for its introduction next year. If there’s a topic of particular interest you’d like me to talk about, let me know in the comments section below.

This blog post was first published on Dataversity on 15 September 2017

Share this post.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

Related posts

Also in Audit & Compliance

SQL Census update: new server view

SQL Census is the latest prototype to come out of Foundry, Redgate’s research and development division. It helps you trace SQL Server user access permissions. You can use it to for free of charge by...

Also in Blog

The real origins of the Agile Manifesto

In February 2001, 17 people met at the Snowbird ski resort in Utah. They were the leading exponents of Extreme Programming, Scrum, and Adaptive Software Development, and they were seeking a set of com...