GDPR for IT Managers & Executives
The Key Data Security Requirements, Compliance Challenges,
and How to Secure Your Data in Time
As an IT Manager, it’s likely your responsibility to ensure your company’s system is GDPR compliant. You’ll have to make sure that whatever database your organization is using offers the data security options necessary to achieve GDPR compliance. As an example, if you’re still using a transactional database, you’re not going to meet the GDPR’s security requirements, meaning you’ll be one of the companies facing those €20,000,000 fines.
Now you know the GDPR will likely affect you, and you might be wondering how to explain the legislation to others at your company, as well as what you can do to ensure compliance. We understand that a lengthy, filled-with-legal-mumbo-jumbo directive can be a bit intimidating to grasp. That’s why we’ve created the ultimate guide to GDPR preparedness for anyone in an IT management role.
Read along, jump to the section that interests you most, or email it to a colleague who needs to know:
The Key Objectives of the GDPR
How to be GDPR Compliant
Challenges of GDPR Compliance with ISAM Databases
How to Move to a Secure Database Before GDPR Enforcement
The Key Objectives of the GDPR
When the EU passed the Data Protection Directive in 1995, each Member State was allowed some flexibility on implementation, resulting in a medley of individual European privacy laws. Since then, globalization, data collection advancements (including targeted collection from search engines, social media, and smartphones), and a sharp increase in security breaches combined to create a perfect personal data storm of sorts. With the importance of protecting individuals’ privacy and personal data now incredibly apparent, the European Union created the General Data Protection Regulation to hold companies to a stricter standard regarding personal data storage and collection.
Because the 99 Articles of the GDPR are lengthy, thorough, and vast, it’s worth noting the legislation’s key security objectives:
Establish data privacy as a fundamental right for everyone. (Recital 1)
Clarify who is responsible for data protection. In short, any company who handles the personal data of a subject located in the EU will be required to comply - whether that company is the collector or processor of that data. (Article 3)
Define standards for data protection. Regardless of their location, anyone handling the personal data of an individual in the EU is required to follow the GDPR. (Article 3)
Mandate the principles of data protection. Namely, data security must go beyond encryption and also focus on risk assessment, preventing attacks, and controlling access to sensitive data. (Article 5)
Increase enforcement power. In the event of non-compliance, the EU’s regulatory body will issue fines up to €20,000,000 or 4% of the company’s global annual revenue, whichever is higher. (Article 83)
How to be GDPR Compliant
Now you know the broad strokes of what the GDPR intends to accomplish, including the penalties that apply if you don’t comply with the new regulation. But how, specifically, do you know whether or not your database is compliant? Are your system and organization compliant already? And if not, what do you need to do to get there?
GDPR PREPARATION
FOR IT MANAGERS & EXECUTIVES
Whether your organization is a Data Controller or Data Processor, use the following guidelines to help prepare for GDPR enforcement
Identify Security Risks
Evaluate and assess the risks involved with your data processing. Take measures to reduce those risks and implement secure processing. Questions to answer:
How are you gathering personal data?
Where are you storing this data, and how is it sent there?
Who has access to the data, and who should not have access?
What are the risk factors involved in gathering and storing this data?
Assign a team member, such as a Data Protection Officer, to be responsible for remediation plans when it comes to holes in your security
Secure Your System/Prevent Attacks
Use industry-standard encryption technology for the transfer, storage, or receipt of personal data
Take steps to obscure and protect customers' personal data, through anonymization or pseudonymization practices
Take steps to obscure and protect customers' personal data, through anonymization or pseudonymization practices
Monitor For Breaches
Perform regular security audits of the personal data in your system, who's accessed that data, and whether and where it has been transferred
Be prepared to notify the GDPR and affected customers within 72 hours of a breach
Keep Security At The Heart Of Your System
Pursue data security be default and by design: make business decisions with security in mind
Be prepared to notify the GDPR and affected customers within 72 hours of a breach
You Must Discover and Assess Risks (Article 35)
In the past, you might have simply relied on your database vendor’s assurances, documentation, and internal processes to gauge your database’s security. With the GDPR, that won’t be enough. While a mature database vendor can provide you with products and services to help you perform your own security assessments, as the Controller of your data, it will be up to you to perform those assessments, and to log the results.
As an example, let’s say you are a hotel chain which holds customers’ names, emails, phone numbers, credit card information, and so on in your database. That’s all (rightfully) considered personal data under the GDPR. To be compliant with the regulation, you must know:
Where and how are you gathering this data.
Where it is stored and how it is sent there.
Who has access to the data, as well as what the potential risks surrounding that access are.
Who should not have access and how you are preventing that access.
What other risk factors may be involved in gathering and storing this data, based on your own unique situation and circumstances.
You Must Discover and Assess Risks (Article 35)
All of these tasks should be carried out under the advice and guidance of your Data Protection Officer. If you’re a larger organization, you might already have a Data Protection Officer, or a Chief Security Officer or Security Administrator who is set to fill that role. If you’re a smaller organization, you may need to look for an outside consultant or talk to your database vendor about whether they have employees who perform this service, or an automated process that can help.
The end result of this assessment is a map of your organization’s data processes, user and customer profiles, and security tools, which you can present should the EU’s regulatory body ask for it. You should also use this map to proactively eliminate existing holes in your security and streamline your data access processes, as many of the GDPR’s other articles require you to.
You Must Secure Your System and Prevent Attacks (Article 32)
To ensure you keep your users’ data safe, the GDPR requires you make data unintelligible to hackers or other malicious entities in the event of a breach. There are several techniques you can use to do so, all of which are supported by mature database systems (some automatically, some with the proper setup). These techniques include:
Encryption: Encryption is a biggie because not only does it make your data more secure, but it might also absolve you of having to notify your customers in the event of a breach. The EU’s thinking is, if you’ve rendered your data unintelligible using encryption, a breach doesn’t actually leave your customers vulnerable. So there’s no need to notify. In this way, encryption can save you time and headaches down the road, should a breach occur against your best intentions.
Anonymization: Anonymization is encryption writ large. Anonymization uses encryption, as well as other techniques like data hashing and generalization, to render data completely unidentifiable, even within your organization.
Pseudonymization: Pseudonymization reduces the risk of a malicious entity linking any individual piece of information they steal to the customer you gathered it from. While pseudonymization does not require you make data completely unidentifiable, it does require you separate data in such a way that a user can identify the data subject only from multiple pieces of information. (There’s a good explainer on the difference between anonymization and pseudonymization here.)
You Must Minimize Users' Data Access
Besides just asking you to obscure and protect customers’ data, the GDPR also requires you minimize your users’ access to that data (Articles 25, 29). For example, continuing our hotel chain example, there’s no need to give your cleaning staff access to a patron’s name or phone number. So they should not be allowed to access that information. By minimizing access, you ensure users can’t intentionally or unintentionally steal information, and malicious entities with access to that user’s login can’t do so either.
Furthermore, what a lot of organizations don't realize is that under the GDPR, gone are the days of special freedoms for super users. To be compliant, you'll need to monitor privileged user database access and activities, plus you'll need the ability to offer a forensic trail of database modifications in the event that your organization is audited.
You Must Monitor for and Notify the EU of Breaches (Articles 30, 33)
Restricting users’ access will also make your life as a Data Controller easier, when you perform GDPR required audits of the personal data in your system, who’s accessed that data, and whether and where it’s been transferred. While performing these audits shows customers your organization’s transparency and accountability, the audits are required primarily because the EU wants to be notified of any breaches you find.
What to Do in the Event of a Breach
If you detect a breach, you must notify the GDPR supervisory authority in “a timely manner,” which the regulation defines as 72 hours or less. You must also notify affected customers within 72 hours or less, unless “the data breach is unlikely to result in a risk to the rights and freedoms of natural persons”. The breach notification must include several pieces of information, including the nature of the breach, the category and number of customers affected, and the likely consequences of the breach.
72 hours is not a lot of time to pull all this information together, but if you’re using a mature database system, their included security alerts and tools can help you meet this requirement, both by detecting breaches early and logging users’ access.
You Must Put Data Security at the Heart of Your System (Article 25)
While you might’ve been okay dodging or deferring some of these requirements prior to the GDPR, the substantial fines that’ll soon be in place for non-compliance should encourage you to bring your database security up to snuff. To that end, the GDPR provides a few recommendations and requirements that will help you move data security from an afterthought to the guiding force of your organization’s data structure.
One of the GDPR’s weightiest recommendations is factoring data protection into your organization’s hierarchy by “design and default”. This means data security can no longer be the last thing you consider as you implement your system. Instead, you’ll want to make purchasing decisions and define and refine processes with security in mind. The GDPR also mandates you implement “appropriate technical and organizational measures,” including but not limited to those we’ve already laid out above. Note that this phrase is appropriately vague and broad, meaning the standard could change over time.
Implementing Centralized Control
To stay abreast of your system’s overall state of security, the GDPR recommends you implement centralized data administration, in which you, as a Data Controller, monitor all of your applications, databases, and data from one central location. Most current database systems allow you to do this easily, so you’ll have no trouble migrating to centralized control as you start (or, hopefully, finish) your journey toward GDPR compliance.
Challenges of GDPR Compliance with ISAM Databases
While we’ve made compliance with the EU’s new General Data Protection Regulation understandable, that doesn’t mean it’s going to be easy. If you’re using older, indexed sequential access method (ISAM) databases like DataFlex and Btrieve, you might find your system falling short as you investigate your data security and examine how you store, access, and update customers’ personal data. And remember, falling short of GDPR compliance can mean significant fines (of 20 million Euros or more).
Below, we’ll lay out some of the larger pitfalls and speed bumps you might run into while readying your ISAM database system for the GDPR’s May 25, 2018 compliance deadline, as well as how you can avoid them using a more robust SQL database system.
The Definition of “Personal Data”
As you know, the GDPR’s all about protecting your customers’ identity, privacy, and personal data. As such, the legislation goes out of its way to define “personal data” relatively broadly. According to the GDPR, personal data is:
“Any information relating to an identified or identifiable natural person; an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.”
That’s a lot of words to say, essentially, that “personal data” is any piece of information that can be used to identify a person. If you store and retrieve data using ISAM database systems (such as DataFlex- or Btrieve-based databases), surveying your system to find and catalog this data will take ages, assuming you’ve even organized your data properly. You could be searching through everything from customer relationship management (CRM) records, to purchase histories, to emails. And as you likely know, ISAM databases’ reporting capabilities are not ideal. You could spend the entirety of the next four months running reports to catalog personal data.
In contrast, the SQL databases offered by companies such as Oracle and Microsoft provide robust data management and reporting options, which should make it easy to find, catalog, and manage the personal data you process or access. Specifically, Oracle offers several database assessment features, such as Application Data Modeling and their Database Lifecycle Management Pack, designed specifically to show you where you’re holding personal data, as well as the connections between those pieces of data. Meanwhile, Microsoft SQL Server offers advanced metadata queries, Full-Text Search, and other tools to do the same.
Whitepaper
Learn how to migrate from Btrieve to SQL without source-level changes
Whitepaper
Learn how to migrate from DataRex to SQL without source-level changes
Anonymizing and Encrypting Your Data
After you’ve identified where you’re storing your customers’ personal data, the next challenge you’ll face is ensuring that data is properly protected. The GDPR asks that you not only encrypt your data, but also “anonymize” and pseudonymize it where possible. While doing these things protects your customers, it also protects you. If you can prove your customers’ personal data is properly encrypted and pseudonymized, you won’t have to report data breaches to those customers, saving you time and money down the road.
However, if you’re operating from an ISAM database, your encryption may not be adequate (or in some cases it may be completely missing). IBM is only now rolling out advanced encryption methods like pervasive encryption, in response to legislation like the GDPR. And you can forget about anonymizing your customers’ data. With ISAM databases, anonymization isn’t even possible.
While you could stick with your ISAM database and hope its security features will be sufficient (and continually updated) after the GDPR deadline, it’s likely better to take advantage of the more mature encryption, anonymization, and pseudonymization options that SQL database vendors offer. Microsoft SQL Server offers several built-in layers of encryption, including Transport Layer Security and Transparent Data Encryption. Oracle also offers Transparent Data Encryption, as well as pseudonymization (via their Data Redaction feature) and anonymization (via their Data Masking and Subsetting features). Together, these features should keep your customers’ data, and your bottom line, properly protected.
Data Erasure and the “Right to Be Forgotten”
As part of GDPR, you not only have to protect your customers’ personal data, you have to be able to easily retrieve, update, and erase it. Specifically, the GDPR sets out new rules revolving around the Right to Be Forgotten, specifying that you must be able to delete all personal data as well as back-ups at a customer’s request, as well as limits for how long you can hold on to a customer’s data.
This is another area where your ISAM database’s lackluster reporting capabilities and lifecycle management features could hurt you. The ability to easily monitor, extract, and delete data is going to be essential after the GDPR comes into force. SQL databases offer automated lifecycle management and data discovery, as well as centralized database management hubs that allow you to get an overview of all your data at once, as well as your compliance with regulations. By comparison, most ISAM databases will require you to string together, monitor, and extract your unstructured data yourself, turning retrieval and erasure requests into a pain.
How to Move to a Secure Database Before GDPR Enforcement
Most of us know all too well that, for one reason or another, public response to government regulations always seems to be running behind. If you’re scrambling to get your company on track for the GDPR’s May 25, 2018 enforcement date, it’s true that your days are numbered. But there’s still time to meet the GDPR’s compliance challenges head-on.
The Need for a Simple Way to Achieve Secure Data Storage
When it comes to your company’s database compliance, the heart of the matter is the GDPR’s decree that a person cannot be associated with their personal data in your database. Why? In the event of a breach (think hackers, or even rogue employees with the right access), the goal is to ensure this sensitive and personally identifiable data stays concealed.
“...Personal data shall be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed…”
(GDPR Article 5)
To achieve this lofty goal, the GDPR encourages data anonymization or data pseudonymization, which we discussed in detail during our previous look at the GDPR’s key data security requirements.
Why SQL Is the Right Choice for a GDPR Compliant Database
As you consider your options, attempting to bring your business up to par before GDPR enforcement, we’d like to remind you that SQL databases are likely your best bet. That’s because in most commercially available SQL databases, DBAs have the option to encrypt data on a per-column basis or to encrypt the entire database. Older ISAM databases, such as DataFlex and Btrieve, don’t offer this option.
Your next concern might be how you can pull off a project of this complexity, moving your existing application to a new SQL database, especially in the time you have left before the deadline. Typically, companies looking to migrate from an older database to a SQL offering have two choices:
Rewrite Your Source Code
Anybody who has experience with coding knows this is a time-consuming option! It’s not just a matter of writing new code for your entire application, there’s also the endless hours of time your team will log testing the new code. And if the time required for this option isn’t scary enough, don’t forget that more time spent also means more money spent.
From start to finish, this entire process could take you anywhere from a few months to a few years to migrate the most complex applications. With that timeline in mind, consider the number of developers you’ll need for a project of this scale, then multiply that number by their average salary. Are you seeing the € (or $) adding up yet?
Realistically speaking, it’s probably too late to pursue a code rewrite this late in the game, keeping time (and budget) considerations in mind. Let’s take a look at another option...
Use a Database Modernization Technology
Choosing this option means you won’t have to worry about costly code rewrites or data reformatting, so there’s nothing to test - making it the fastest, cheapest solution. In fact, it’s possible to go live on a SQL database in as little as a few weeks!
Here’s how it works: Mertech’s database modernization tools such as BTR2SQL and Flex2SQL provide a way for companies to migrate their data to SQL DBMS and then run their existing applications with the newly migrated database, without requiring large scale changes to the source code.
The result is an easy, cost-efficient migration that provides you access to databases with the anonymization, pseudonymization, and encryption features we described earlier… the cornerstone of data security efforts as declared by the GDPR.
Learn how Bank of America saved over 4,000 hours of developer time
while migrating from a Btrieve application to an Oracle database.
SQL Benefits Beyond GDPR Compliance
Lower Cost of Ownership. Don’t get stuck paying more and more to use your old database, when you could move to a lower-cost option such as Oracle, Microsoft SQL Server, PostgreSQL, or MySQL.
Lower Cost of Ownership. Don’t get stuck paying more and more to use your old database, when you could move to a lower-cost option such as Oracle, Microsoft SQL Server, PostgreSQL, or MySQL.
More Robust Reporting. As Dealer Management System vendor CDK Global has explained, making the move to SQL opens up in-depth reporting options, allowing you to easily stay up-to-date on complex business trends.
Get Started on Your Transition to SQL
If you are a European company that deals with personal data, or a company located outside the EU that conducts business there, you need to be aware of the impact the GDPR may have on your business - especially if you have not transitioned to a secure database.
Learn why more than 9,000 companies across five continents chose Mertech to save millions of dollars and countless hours of developer time, using data migration tools and data connectivity drivers. Get started on your move to a more secure database with a free trial of BTR2SQL for Btrieve applications, or a free trial of Flex2SQL for DataFlex applications.
It’s not too late to start preparing for GDPR compliance!
