5 Ways to Make Your Database GDPR-Compliant

Though we’ve known it’s been coming for nearly 2 years, the mad rush to meet GDPR requirements is peaking now. As GDPR regulations apply to any organization worldwide that collects or manages the personal identifiable information (PII) of EU and UK citizens, virtually every digital organization in the world needs to comply. Non-compliancy penalties are steep and can reach as high as €20 million or 4% of the perpetrating organization’s annual global revenue, whichever is greater.

Complying with the 88-page, 92-article regulation doesn’t have to be a nightmare; there are plenty of tools and technologies out there that can help you implement “privacy by design” into your data management systems. Ticking off these boxes will not only ensure that the data you collect is held to the strictest standards, it can also help ensure that your money stays in the bank (rather than the collection accounts of the EU).

GDPR in the Database – Does it Have to Be a Nightmare?

In a word, no. In 5 words—it doesn’t have to be. There are some measures you can take to minimize the headache. Databases, by nature, contain a great deal of what GDPR calls PII; for that reason, anyone who comes in contact with databases will fall under the GDPR’s definition of a “data processor,” who is responsible for meeting the compliance requirements. In this context, data processors can include IT team leads, Devs, DBAs, QA teams, release managers, DevOps engineers, and many others.

Here are a few ways you can make sure your database is secure and compliant with GDPR, without bending over backwards or breaking the bank:

1. Create and Enforce Roles and Permissions

Recital 39 of the GDPR states: “Personal data should be processed in a manner that ensures appropriate security and confidentiality of the personal data, including for preventing unauthorized access to or use of personal data and the equipment used for processing.” Who can make changes to data, data structure, tables, and schemas? What kind of changes can be made? By defining roles and permissions on the database level in advance, you can prevent unauthorized access to sensitive PII. This is a smart security move for your organization in general, and can assist in preventing catastrophic errors and loss of data (like this poor guy who accidentally deleted an entire database his first day on the job as a junior developer—an action he certainly shouldn’t have been able to carry out).

2. Mask Sensitive Data

Article 32 and Recital 83 of the GDPR address the issue of maintaining security and privacy in data processing. As data often needs to be passed backwards and forwards between environments for the sake of development, testing and deployment, it may fall into the hands of multiple individuals along the way. In order to maintain the utmost level of privacy and protection for the individuals whose information is being processed, encryption or pseudonymizing technologies can easily be implemented on the database level. Data masking within the database ensures that the developers and engineers can use real data when working on their databases, without compromising any individual’s privacy or breaching any articles of the GDPR. Look into technologies like the Delphix Dynamic Data Platform for masking data.

3. Produce an Audit Trail of Database Activity

Keeping track of who did what, when, and why it was done in the first place, is not only crucial for your own business management but for demonstrating compliance as well. Having a complete history of all the changes made to a data structure on the backend is critical for the sake of security, accountability, and detecting the causes of errors. Moreover, Article 24 of the GDPR requires organizations to demonstrate the security measures implemented for the sake of compliance; documentation of all database activities is a great way to do this. Should your organization ever be audited by EU officials, having a detailed, documented history may just help you pass.

4. Create Alerts That Notify You of Breach Attempts

If you follow suggestion #1, you’ll have roles and permissions in place to prevent unauthorized parties from accessing or making changes to the database. Using the right tools, overseers can see when attempts were made (and denied) to make changes in the database. Some database tools will go as far as to alert designated personnel when these attempts are made, with the purpose of raising immediate attention to suspected malicious activity or breaches. This is not only a brilliant security measure for the protection of crucial data, but will assist you in meeting Recital 39 of the GDPR.

5. Prevent Configuration Drift and Data Loss

A big piece of the GDPR puzzle has to do with loss and alteration of PII data. Maintaining the integrity of PII is just as important as the security measures used to collect and store it. GDPR Article 32(2) refers to the measures that must be taken to prevent “accidental or unlawful destruction, loss, alteration, unauthorized disclosure of or access to personal data.” Putting aside intentional edits, disclosure or deletions made to PII, accidental removal or edits to the data are a bit harder to prevent.

We’ve all seen it: A live version has a critical error that needs to be addressed immediately. A hotfix is pushed directly into production—crisis managed—but in the heat of the emergency, the fix isn’t deployed into lower environments (DEV, testing, etc). The result – later versions cause configuration drift that destroys that much-needed hotfix, and quite possibly changes or deletes precious data. Use a tool that alerts you to possible drift occurrences, compares versions, and halts deployments when drift is detected. It’ll save you a lot of time, money and grey hair, and will help you meet GDPR as well.

Still have questions or concerns about GDPR in the database? Join the webinar on March 14th, hosted with Jodi Daniels, privacy expert and founder of Red Clover Advisors. All these topics and more will be discussed.