Loading...
You are here:  Home  >  Data Education  >  BI / Data Science News, Articles, & Education  >  BI / Data Science Blogs  >  Current Article

So, What is GDPR and Why Should Database Administrators Care?

By   /  September 15, 2017  /  1 Comment

Click to learn more about author Richard Macaskill.

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.

About the author

Richard is a Product Manager at Redgate, having previously spent around 20 years in IT management, database administration and development for Insurance and Financial Services firms in London, back-filling other roles along the way. He spends much of his time boring anyone in earshot about the DevOps and automation implications of financial compliance and audit. Follow Richard and Redgate at: Richard Twitter, Redgate Twitter, Richard LinkedIn, Redgate LinkedIn, Redgate Facebook

  • Hari Kumar Mindi

    What would be the implications of non-EU companies who are vendors of EU companies. Specially there are DBA’s sitting outside EU and managing the servers in EU datacenters remotely.

You might also like...

Data Governance Best Practices: Five Industry Experts Discuss Their Viewpoints

Read More →