It’s safe to say that you’re always learning in your role as a database administrator. There’s a lot on your plate when it comes to SQL server monitoring, for sure, but now you also have the General Data Protection Regulation (GDPR) to worry about, too.
Learning everything you can about GDPR compliance is crucial for your company and its databases. Jam-packed with legalese, the GDPR does make one thing clear: that you, as DBA, are responsible for the access and protection of any information whether on-premise in your own data center or within your cloud services Let’s take a closer look.
What is GDPR?
The GDPR is a European privacy law that took effect on May 25, 2018. Its fundamental purpose is protecting the privacy rights of individuals while establishing global privacy requirements regarding how personal data is managed and protected.
While it’s a law aimed to protect citizens of the European Union, any company that has an EU citizen in their database must comply with GDPR requirements. Personal data includes birthdates, credit card details, email addresses, IP addresses, photographs, national identification numbers, and more.
As a DBA, you not only need to ensure that personal data is protected from unlawful access, but also that a user can access and obtain a copy of his or her personal data.
Not abiding by GDPR regulations comes with heavy consequences; organizations are fined up to 4% of their global revenue or up to 20-million pounds making it vital for companies to take action immediately and be in full compliance by the time GDPR requirements are in full-force.
So, what’s next for SQL server monitoring?
Now that the May 25 deadline has passed, you will hopefully have completed a risk assessment. For instance, does any of the information you’re storing involve companies and individuals of the EU, or will it in the future?
If the answer is yes, then you have to consider a variety of questions, including where you store personal information, what the information is used for, whether you make it clear to users that you’re storing the information, how long you maintain it, who has access to it, etc.
Ideally, you could simply search all of the data on your SQL server to look for column names such as “SSN” or “Birthdate,” but columns are often labeled with obscure, cryptic names. That means you may have to spend time manually investigating every single table. Determining who has access to data may be difficult to determine, as well.
If you’d like a general assessment of your organization’s GDPR readiness, this survey can help.
Sifting through the (mountain of) information
Unfortunately, learning everything there is to know about GDPR compliance requires hours of reading and research. There are 99 articles and 11 chapters on the GDPR information website, which may take you days to research in its entirety.
That said, here are some articles that may most pertain to you as a DBA regarding SQL server monitoring:
Article 25 addresses data protection by design and default, i.e., controlling who has access to personal data and how the information is stored, processed, and accessed.
- Data privacy by design means that appropriate organizational and technical measures to ensure personal data security and privacy are embedded into the complete lifecycle of an organization’s products, services, applications, and business and technical procedures. Technical measures can include, but are not limited to, pseudonymization and data minimization.
- Data privacy by default means that (a) only necessary personal data is collected, stored, or processed and (b) personal data is not accessible to an indefinite number of people.
Article 25 also specifies that an approved certification, as specified in Article 42, may be used to demonstrate compliance with the privacy by design and privacy by default requirements.
This article addresses the proper auditing of all records and personal data. The requirements for Article 30 are likely to apply to most companies because of the article’s broad applicability. Companies preparing to comply with Article 30 should look at how data moves through each of its business processes, not just where the data resides. In other words, “follow the data.”
Article 30 requires companies to produce “records of processing activities,” which will allow regulators to see that companies are adhering to GDPR.
Article 32 covers the requirement that data is encrypted. It requires DBAs to implement technical and organizational measures that ensure a level of data security appropriate for the level of risk presented by processing personal data.
Data security measures should, at a minimum, allow:
- Pseudonymizing or encrypting personal data.
- Maintaining ongoing confidentiality, integrity, availability, access, and resilience of processing systems and services.
- Restoring the availability of and access to personal data, in the event of a physical or technical security breach.
- Testing and evaluating the effectiveness of technical and organization measures.
This article outlines the proper documentation of all the data protection methodology and their need and impact. All organizations are required to analyze their risk and demonstrate their compliance with GDPR.
It stipulates that a Data Protection Impact Assessment (DPIA) should be carried out if the processing of data is likely to create a high risk. A DPIA is an exercise that enables a business to examine the risk that may be associated with the processing of data and a way to review their procedures with GDPR compliance in mind.
The article also calls for supervisory authorities to create and publish their own lists of data processing activities that will require DPIAs.
Getting ready for GDPR compliance is no easy task. If you have not already done so, take advantage of all of the information and research available to help you become compliant as quickly as possible.
Take further action to improve your SQL Server monitoring. Begin future-proofing your databases with our free guide.