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

Updated November 2018

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. It came into effect in May 2018.

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 was charged with enforcing the law in the UK.

“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 needed 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 prepared by now and have got his or her estate in order, ahead of the May 2018 enforcement date.

Probably the biggest was that the new law required ‘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 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, ask yourself 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 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 Data Protection Officer ?

This isn’t all you need to prepare for, but it’s an important first step in ensuring you’re compliant with GDPR. So, if you haven’t already, start the conversation, take the lead if you can.

It’s not too late to start your GDPR journey now.

You can find out more about keeping sensitive data secure on Redgate’s Protect and Preserve Data page.


If you’d like to gain a deeper understanding of the GDPR, you can also read Richard’s other posts on the topic:

So what is GDPR, and why should your customers care?

So what is a Data Protection Impact Assessment and why should organizations care?

So what is data mapping and why is it the key to GDPR compliance?


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