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.

You can find out more about keeping sensitive data secure on Redgate’s Data Privacy and Protection pages.

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

Tools in this post


Deliver GDPR-compliant data to SQL Server teams

Find out more

Share this post.

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

Related posts

Also in Blog

Why code quality is vital in the world of database DevOps

Everyone understands the importance of code quality for applications, particularly when DevOps results in releases becoming faster and faster, reducing the room for error. The same issues increasi...

Also in Audit & Compliance

Traditional database security doesn’t protect data

It seems every week there’s a new data breach to read (or tweet) about. I recently discovered this lovely visualization of the growing amount of private data about people like you and me that is bei...

Also about GDPR

Automatic Provisioning of Developer Databases with SQL Provision

The GDPR, and other regulations, requires that we be careful in how we handle sensitive data. One of the easiest ways to avoid a data breach incident, and any accompanying fine, is to limit the sensit...

Also about Data governance

Redgate data governance survey reveals database DevOps is the key to GDPR compliance

A major new data governance survey from Redgate demonstrates there are important GDPR compliance issues that need to be addressed – and that a DevOps approach to database development can provide the...