5 Questions Database Admins Should Ask About Compliance Regulations
While the U.S. has regulations that cover data privacy — HIPAA, HITECH, PCI and the new Californian CPA come to mind — GDPR is the most comprehensive set of regulations when it comes to protecting personal data, carries potentially huge fines for non-compliance (4 percent of annual worldwide turnover or nearly $23 million [€20 million] — whichever is the higher) and it’s sparking a fundamental rethink of security and compliance. As a database administrator (DBA), this can be challenging to understand and adapt to.
DBAs are finding themselves on the front lines of protecting data, which is a new wrinkle impacting daily roles and responsibilities. If DBAs and their teams carry on without taking the time to understand sensitive data across their systems, their company can run the risk of being non-compliant, potentially receiving fines, or becoming at risk for different threat vectors.
So what do today’s DBA’s need to ask themselves to ensure the data they are responsible for is properly managed, secure, and not sensitive to threat vectors in light of evolving compliance requirements?
Here are five questions to help get started:
- Do you know where your sensitive data lives?
GDPR introduced a new concept called Privacy by Design that requires a fresh look at how businesses should design their systems, with data privacy as a priority. The first question to ask yourself to ensure your business is protected, is to find out (if you don’t already know) where sensitive data exists in your databases.
More importantly, make sure you know what constitutes sensitive data to properly account for it. GDPR defines personal data as “any information relating to an identified or identifiable natural person (‘data subject’); 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 number, 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.”
In simple terms, personal data can range across a spectrum of data, and can include, but is not limited to:
- Biographical — date of birth, email address, phone number
- Physical — eye and hair color, weight, height, gender
- Work — salary, tax
- Cultural — religion, political affiliation, leisure activities
- Health — medical history, genetic
If your business has customers and end users in EMEA, make sure you know where your sensitive data lives and that you’re defining it properly to be prepared for compliance.
- Does your company have a dedicated data controller?
GDPR is the most stringent data regulation to-date, and it specifies multiple roles, such as controller, processor, sub-processor and data subject, to ensure a company complies with all regulatory requirements.
Does your company have a dedicated “Controller,” such as a data protection officer or manager? If not, the DBA may soon find him (her) self-tasked with identifying personal data in your systems and implementing data protection measures, so it’s important to begin evaluating next steps now.
While the Data Protection Officer role has yet to be seen as required for U.S. laws, it may be helpful to at least identify who would be responsible for that task if and when it’s needed.
- Are your systems built for automation and with data security in mind?
GDPR mandates that Controllers perform data protection impact assessments when certain types of processing of personal data are likely to present a “high risk” to the data subject. Each assessment must include a systematic and extensive evaluation of the organization’s processes and profiles, and how they safeguard the personal data.
As a DBA, data privacy and security risks should be a quickly growing concern for a few reasons:
- Enterprise databases likely contain personal and other sensitive data.
- Databases are a primary target for malicious actors attempting a data breach.
- Most regulations specifically prescribe methods and techniques that must be used for databases.
- The DBA is often primarily responsible for implementing compliance controls and technical measures for protecting data.
When you’re adjusting for GDPR and other data regulation requirements, it’s helpful to automate the process of discovering sensitive data in all your databases and having a tool or process or system running reports for you.
Your goal is to monitor that data in real time, and notify database developers of potential breaches before they deploy code changes into production systems. The alternative is undertaking this extensive monitoring process by hand — but I promise you’ll sleep better at night if you can incorporate automation.
- Are you equipped to prevent personal data breaches?
There are two main ways to protect personal data: pseudonymization and anonymization.
Pseudonymization enhances privacy by replacing most identifying fields within a data record by one or more artificial identifiers, or pseudonyms. There can be one pseudonym for a collection of replaced fields or one pseudonym per replaced field.
Anonymization obscures personal data by masking it, for example. Once anonymized so that the individual is no longer identifiable, the data is safe, isn’t it? Not if the anonymization process is reversible. If it can be reversed, it’s still personal data. The method of anonymization needs to be irreversible for it to be truly anonymized.
Whichever approach you take, make sure your system is equipped with the best data protection features for the job.
- Do you know how to monitor data for potential breaches — when data is constantly moving?
Traditionally, data has been stored in one place — the database — with backup copies on physical media. That media is usually in a different location from which it can be restored in the event of a data loss.
But in this era of data protection strategies that includes high availability (HA) and disaster recovery (DR) systems, data is continuously replicated to other locations and to the cloud (DBaaS or IaaS). That continuous movement makes it difficult to identify and protect personal data — especially as DevOps and cloud initiatives essentially function with continuous movement.
To combat this, it’s important to ask yourself: do you have monitoring tools in place for your HA, DR, cloud and DevOps systems?
With database activity monitoring tools, you can monitor important aspects of user behavior including the following types of operations:
- DML — (Select, Insert, Update, Delete) where such data changes may involve the use of sensitive data
- DDL — structural changes to database objects
- DCL — changes to user access rights
- TCL — transaction control
With tools monitoring at those levels, you’ll have a better chance of detecting the potential for data to end up where you don’t want it — and even prevent that from happening at all.
Keep in mind: GDPR May Be EMEA-Focused, But Increased U.S. Data Regulations are Coming
Even if your business isn’t immediately impacted by GDPR, it’s informative as to what eventual U.S. regulations may entail. And depending on the states your business operates in, you may need to adjust sooner rather than later.
Ultimately, the quicker you act on asking yourself the right questions, the quicker and more prepared you’ll be for maintaining business operations — while the competition scrambles to adapt.
Feature image by Dimitris Christou from Pixabay.