Security and protection of personal information (PI) is all the rage today, and the EU has launched legislation called the GDPR to do something about it. You can’t scroll through Facebook or watch the news without seeing something about the latest data breach.
The days are numbered before the U.S. joins the European Union in their General Data Protection Regulation (GDPR). In the EU, PI data not only includes name, birthdate, SSN and health data related to a specific individual, it also covers, religion, sex, race, IP address, residential address and phone number. Anything that points to or belongs to an individual is protected.
As Database Administrators (DBA), we must get ready for GDPR changes and how these can will affect your daily work life.
The first thing you need to know is that if you are working from the U.S. on data residing in the EU, you are responsible for following GDPR. Second, if you are a provider for a company that stores, manages, or moves data in and out of the EU you also have to follow the protocols.
Steps to Comply with GDPR
To comply with GDPR, make sure you are already following these security best practices in your database:
- Are you using roles and privilege controls already allocated for you in the database tool?
- Do you have a security officer that controls who has access to what inside the database?
- Do you have system administrator roles limited to key individuals?
- Are you testing in a cloned environment before rolling new code into production?
- Do you limit who has access to roll the code up?
- Do you have standards for writing code are you using a versioning tool to track who made what changes, when?
The next step is to ensure you have standard password and role security in applications, instilling password change requirements at time intervals. Are you using https and SSL certificates in your web applications? Ask your developers if they are doing the front-end protections while you are setting up the back-end security protocols.
PI data should be masked everywhere it can. Limit who can handle data modification directly in the database. Have a security officer help be the second set of eyes if you are modifying individuals’ information, or better never modify data without an application. You should track these changes very closely and have a second set of eyes protocol if you need to make these changes. Also, backup the data in case you need to recover before you complete any modifications to the data.
If you don’t have processes in place for this work begin by writing up ideas and protocols that you believe would be necessary to protect your job and yourself. Think about CYA in this instance, don’t feel bad about doing this. If you are protecting yourself you are also protecting your company. If a mistake happens or worse a security breach occurs you want to be sure you are able to recover the data, protect your job and mitigate any legal action that may take place for your company.
Your job is, after all, ALL ABOUT THE DATA. Becoming a soldier that stands at the door to protect it is your job. Your job is to open the floodgates when your company needs to access the millions of rows of data it needs to run reports, compute and analyze and, at the same time, locking it up so the enemies within and out of the gates cannot destroy this asset.
In summary, review your standards; are you following the best practices for your industry? Do you have protocols in place for modifying PI data? Is everything backed up properly? Are you running on the latest security patches? Is all software compliant? Are you using roles and privileges properly? Are our production DBAs the only ones in your production database? Developers need a place to work and to play but that is never in your production environment.
Do you have protocols to protect you when asked to modify production data? Modifying production data means deleting, updating or adding information. Is the PI viewing limited to eyes only? Do you have a second to verify the changes and that the queries are correct? Did you backup the data and store it just in case? Did you get the instructions and final testing results signed off by a security officer (GDPR will require a Data Protection Officer to be added to a job description or a new team member)?
Contact Soaring Eagle Consulting for Consultation
If you can say yes to these questions, congratulations! If you have some concerns or you are worried about any of these responsibilities, contact us today to discuss how our database consulting services can help you with PI security.
