Bring your pencils out and take some notes

Developing in the cloud in the age of GDPR

Brian Johnson
© Shutterstock / SB_photos

GDPR is all about the data, and specifically the personal data of people residing in the EU. What will be the future of cloud applications after its enforcement on May 28th? Here’s how to deal with the new circumstances.

The European Union (EU) will begin enforcing the General Data Protection Regulation (GDPR) on May 25, 2018 and those organizations who are non-compliant will face stiff penalties. GDPR is all about the data, and specifically the personal data of people residing in the EU.  It doesn’t matter where your company is based if you collect, process, or hold data of EU residents then GDPR will apply to you.

Importantly, developers building cloud-based applications must become cognizant of data flows in a way that perhaps wasn’t relevant pre-GDPR.  You also must take data breaches even more seriously and have the processes in place to ensure that you report them within three days.

Increasingly, developers are building applications that rely on a portfolio of interconnected services that may span multiple clouds/vendors. This creates a lot of complexity when you now must comply with GDPR that requires companies to track, protect, and in some cases destroy personal data (think of “right to forget” and similar requests).

You must map out your data, and fully understand where it is going, how it gets there, and where and how it is stored. Is the data always encrypted?  What kind of third or fourth parties does the data pass through?  As you build out cloud-based applications, are you considering fourth party risk (risk from one of your vendor’s third parties) when it comes to data handling and breaches?

Do all the services you leverage in your cloud-based application allow you to wipe data?  Do they allow you to do so within the 30-day allowed window?  Do they provide the visibility and granularity you will need to comply with GDPR, and perhaps balance this with your conflicting business requirements?

SEE ALSO: GDPR — Designing privacy and data protection

The EU built GDPR to fundamentally reshape the way that companies approach data privacy, and that is going to require developers to architect (or re-architect) applications to allow the business to comply with GDPR. The EU has armed regulators with a big stick. Companies in breach of GDPR can be fined up to four percent of annual global revenue or €20 million (whichever is greater).

You can go down the rabbit hole quickly and it pays to get some good advice on GDPR while designing your applications, especially in the cloud.  For example, you have to comply with the GDPR data removal requirements, but on the other hand, an e-commerce application may need to retain some data.  My advice is as follows:

Ask for advice.  Find an expert in GDPR to ensure that you fully understand what your responsibilities are and how to implement them in the real world. Make sure you know what qualifies as personal data.  For example, under GDPR this includes location data and online identifiers.

Get to know your data.  Identify what data your company is processing and if it falls under the purview of GDPR. Document your data flows, including inside of third or fourth party vendors. Don’t let your third party or fourth party, vendors/services be black boxes. Dig in and don’t take no for an answer until you fully understand the ins and outs of your data flow fully. Find out if you need all the data you are collecting.

Make security and governance the foundation of all your decisions.  With the massive fines that can be levied for non-compliance, security and governance can’t be an afterthought. These ideas must now be foundational when designing applications and the underlying infrastructure.  It needs to be holistically included in all elements of the application design, development, and testing, and can’t be relegated to an occasional review by one team.  Everyone on the team – developers, UX, marketing, legal, product management, etc. – needs to be thinking about security and governance.

SEE ALSO: Why you should be thinking about data privacy and cyber liability

Don’t reinvent the wheel.  In the cloud, the shared responsibility model means that there are lots of ways to poorly configure your cloud applications and underlying infrastructure. Don’t reinvent the wheel and try to figure out baseline security from scratch.  Standards like NIST Cybersecurity Framework (NIST CSF) offer a great starting point.

Implement automation.  In the software-defined microservice world of the cloud, the rate of change and scale has outstripped the ability for a person, team, or even a company to keep up manually.  This is especially true as it applies to security and governance. Studies have repeatedly demonstrated that companies relying on manual intervention get caught in a vicious cycle, oscillating between compliance and non-compliance.  It is vitally important to define processes that support standards (like NIST CSF) and then deploy systems that allow you to automate enforcement of these standards. In this way, you can maintain a consistent security and governance posture.



Brian Johnson

Brian is co-founder and CEO of DivvyCloud where he leads corporate strategy and product innovation with the goal of making security, compliance and governance accessible for those running hybrid, multi-cloud environments (and thus enabling the future of cloud computing). His career has involved a number of research interests, and the opportunity to develop practical applications.  Areas of focus include cyber threats, information security, automation, hybrid cloud, and software defined infrastructure, such as building serverless architectures with microservices and container deployments.

Inline Feedbacks
View all comments