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. 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

Tools in this post

GDPR

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 Audit & Compliance

Enter data privacy. Exit SQL Server 2008.

SQL Server 2008 and SQL Server 2008 R2 are out of extended support as of July 2019, but the end of bug fixes, security updates and ongoing support has far-reaching data privacy implications, as James ...

Also in Blog

Learning from the Accelerate “Four Key Metrics”

There's been a lot of excitement about the book Accelerate, which summarizes research from the past several years of the State of DevOps Report from DORA (which Redgate sponsors).

Perhaps the most po...

Also about GDPR

Is Google’s $57 million GDPR fine a wakeup call for every IT professional?

Enforcement of the GDPR began in May 2018 and across the EU it seems to have been a relatively quiet period, with few fines handed down for non-compliance. Indeed, most organizations probably think al...

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...