New regulations and standards don’t faze me. I’ve been developing for nearly 20 years now, and I glided through the “inconveniences” of PCI and HIPAA. Y2K? Ha! While others prepped for a technology apocalypse, I was updating SQL 6.5 databases to four-digit years (occasionally glancing up to check the plane overhead wasn’t plummeting towards earth).
When I first learned about the coming of GDPR, I really wasn’t worried at all. Another day, another regulation. Or so I thought. But even just skimming the surface of what GDPR means proves it isn’t just another regulation. Should I be worried? Should you?
General Data Protection Regulation (GDPR) doesn’t sound very exciting, does it? I mean, if we’re meant to be worried about something, it should have a proper name, like, Tactical Obliteration of Information Initiative—TOII (pronounced Toy... hmm, scary-sounding regulation names are harder than they seem!)
Despite its anticlimactic nomenclature, there’s barely an organization in the world that isn’t afraid to whisper its name. And with good reason. From banking to education, just how much of an impact Europe’s new regulations are going to have on consumers and businesses worldwide is yet to be seen. As are the associated record-setting legal fees yet to be applied.
If you thought for a minute that GDPR wasn’t your problem, think again! GDPR has global reach and if you store any information about European users, GDPR will apply to you.
What Is GDPR Again?
Likelihood is, you’ve already sat through more than your desired number of presentations on the legal impact and ramifications of GDPR. I should probably apologize for the next couple of paragraphs that walk through the basics for the other readers, but something tells me a little recap and summarization of what it is wouldn’t hurt.
GDPR is all about protecting people’s information. Our digital lives and interactions have become cleverly and heavily designed around the information someone has about us. While this can be a win-win for consumers and businesses alike, the need for stricter control and regulation is evident. With the right information (and less of it than we’d like to think), you can steal a person’s complete identity and cause untold horror to their careers, relationships, and Candy Crush score.
What with most laws covering online data being drafted in the mid-1990s, it’s about time. I mean, sure, we had America Online (AOL), Windows 95, and incredible 56K modem speeds (!), but we had no idea that one day we’d all be online more than off, and would all be chronicling each moment of our lives on multiple social media and other sites, opening ourselves and our lives up to serious vulnerabilities.
GDPR is all about trying to protect that data. It’s about giving you back the control of who collects it, how it is stored, and what is done with it. It’s about ensuring companies look after whatever information they hold about you and comply with your “right to be forgotten”. It’s about recognizing that your personal data belongs to you.
That all sound great, when “you” are the one being protected, what about when you’re the protector?
Starting to Sound Like a Big Deal?
OK, so perhaps a little worry wouldn’t be misplaced. I mean, GDPR comes with a lot of implications for everyone in any industry and they run very deep. We (especially developers) need to start educating ourselves now to be ready for its arrival.
So, what do we need to know? Let’s dive into a few key areas.
Understanding data
As with most things, there are things you know you know and things you know you don’t know, but you probably don’t know quite how much you don’t know. Best not to be too foolhardy here and make sure that you and your team are well versed in the new rules and regulations. This means cramming up on GDPR and (sorry to say) sitting through more than a few presentations about it with your legal advisors. Let’s face it, this is the only way you’re going to fully grasp what the new standards mean to you. It’s the best way to give yourself a foundation for action.
What data? Where data?
Once you’ve got your head around the laws, it’s time to start performing a full check of your entire data catalog and identifying anything that the new laws apply to. If that sounds like a big job, you’re right—it’s kind of massive, so start soon. Scour every table and examine all your systems for any personal details about your users. Make a note of anywhere and everywhere you find GDPR-centric information.
Some savvy software vendors already offer reporting capabilities to identify this information, like Microsoft’s new Compliance Manager, which helps you scour your Office 365 systems for any areas that need addressing. Some CMS vendors, like Kentico, offer built-in modules that help you identify GDPR information and report it to your users. Leverage these tools as much as possible to save yourself time (and headaches).
Once you know what information you’re storing, you need to start looking into where you’re storing it. Everywhere—each bit of software that sees or accesses the data needs to be reviewed and updated, so be as thorough as possible and keep good logs. If you’ve always wondered what that mystery machine by Accounting does, then now’s the time to learn.
Controlling data
You’ll hear a lot about user rights as you perform your GDPR deep dive, which is good, as protecting an individual’s information is the whole point. But it does mean you’ll have to accommodate some new procedures as part of compliance. Your solutions are going to need the option of controlling data at a much more granular level. You’ll need to understand what additional capabilities you’ll need so you can make them part of your action plan. Some can have pretty hefty impacts on development costs—you won’t want to be hit with surprises later on.
Removing data
One of the main goals of GDPR is to limit the amount of information a company can store about a person. This means certain things like race, date of birth, and which Games of Thrones character you’re most like (along with other unnecessary information) should be removed from your data catalog. (Jon Snow, if you were wondering).
Something else that will have a huge impact on how companies store data (and how developers create data-centric or data-dependent applications) is that people will be given the option to remove their information and be “forgotten”. I can hear all developer-readers’ brains sifting through the numerous data touchpoints that will now need to be updated in preparation for this.
Don’t Panic. Just Prep.
Before you start Googling “self-sufficiency for ex-developers”, breathe. It’s not that bad! Take things step by step. There’s still time.
Make sure you have a clear idea of how GDPR will impact your applications, how you need to update the code, and which features you need to add. Forewarned is forearmed, so arm yourself.
Develop a plan
Armed and ready, now you just need to make it happen. First off, define a complete and thorough implementation plan. Not only does it look good on Kanban, but it really will help you stay on track and on top of the schedule.
Map out all the data you gathered in the discovery phase and break it into logical segments that you can start dividing among your team, and then get on to securing resources you identified as lacking.
Have a clear out
Make Maria Kondō proud by removing all excess data. Less data means fewer headaches over how to protect it. If that doesn’t spark joy, I don’t know what will.
You may well find that your marketing team is storing entire family trees for each site visitor. If this data isn’t essential, get rid of it! Review every piece of information you’re storing and see what you can live without. The less sensitive data you hold about your users, the smoother your GDPR transition will be.
Define “essential”
GDPR has a lot of rules around data. I know. Another big area for concern is how that data is stored, backed up, and accessed. Part of your action plan should include an examination of who within your organization has access to the information. Conduct interviews with personnel, refer to your Disaster Recovery (DR) checklists (remember those?), and limit access wherever you can to just those for whom the data is essential. Trust me, those struck from the list won’t miss it and you’ll thank yourself when it comes to reporting information in an audit.
Audits? Yup.
Know your sh*t
I mean, what’s the good of new regulations if no one is enforcing them? And they will. Maybe not today, maybe not tomorrow, but mostly likely a day you least expect it and have seemingly more important things on your plate. But if you’re well prepared, you won’t even break a sweat! By getting yourself prepped now and implementing a system designed around compliance, you’ll be well equipped to answer auditors’ questions and hand over fancy logs and colorful reports about how well you comply.
Conclusion
As a developer, you’ve got to be confident, see impossible obstacles as exciting challenges, and never admit defeat. So, though GDPR may well test your mettle, have no fear. GDPR is merely another evolution in a long line of standards that affect our development life. As long as you don’t let yourself get daunted by the preparation, and manage yourself with the same integrity you always do, execution will be a breeze.
So, are a developer with a fear of GDPR? Hope this blog post put your mind at ease. Maybe you have already thought about some of the points raised here. Don’t be shy, comment below. We always welcome readers’ thoughts. The topic of GDPR is one that is dear to our hearts. Check out some of the critical points you should be addressing here.
DISCLAIMER: All data and information provided in this blog post are for informational purposes only. Kentico makes no representations as to the accuracy, completeness, currentness, suitability, or validity of any information contained herein. We recommend consulting with a lawyer for any legal advice pertaining to GDPR compliance.