Tackling GDPR Challenge #4: Privacy by Design and Default

by Bill Bradley on Monday September 28, 2020

Part 5 of our Top Challenges of GDPR series provides tips for implementing a key requirement of GDPR: privacy by design and default.

Welcome to part #5 of our series on the top challenges organizations will face once GDPR goes live May 25, 2018. In this installment I will discuss the Privacy by Design & Default requirement. This requirement helps alleviate the issues that inevitably arise when organizations attempt to “add” security to a project, program, application, etc. that previously had not considered this need. This is often due to a lack of integration and minimal considerations for what “secure” truly means when entrusted with sensitive, personal data.

Below is the relevant section from the GDPR itself:

This requirement may elicit a response of “it’s about time” from security professionals, and the general public may too have this sentiment once they take a moment to think of its impact. As an example, look at the proliferation of IoT devices that, based on the results of countless security assessments, had “time to market” prioritized well ahead of “security” on the list. Flip the script here to place security higher up the list and earlier in the development process and these devices would be delivered to consumers, who may be unaware of the risks, with a higher level of built-in resilience. Will this prevent the next botnet DDOS attack? It may not prevent it, but the fewer devices to generate bogus traffic, the easier it is for a DDOS attack to be mitigated.

What are the top challenges to the Privacy by Design & Default requirement?

While some organizations take security seriously and build it into everything they do, this corporate culture is the exception rather than the rule. For the majority of companies, security now needs to be made part of the initial discussions, during the development process. Security can no longer be the last thing done, often in a rush, prior to releasing a new offering.
Organizations must also limit what data they collect to an as-needed basis to minimize the extent of data processed and potential data exposed in an incident. While collecting as much data as possible at once might be easier for the business, GDPR puts limits on this, stating that by default “… only personal data which are necessary for each specific purpose of the processing are processed.” Limits are also imposed on the length of time data may be stored; this concept of a “freshness” date for subject data adds inventory aging requirements to organizations who may not have implemented these practices prior to GDPR.
Access shall also be limited both to who can access subject data and how it can be accessed. Data must not be accessible without an “…individual’s intervention…” to limit automated processes and the risk of data leaks by those processes. Data access shall also be limited; we all know that the entire company doesn’t need access to personal data. GDPR now says technical and/or organizational measures are required to enforce this.
Finally, documented proof of all the above is required. In the event of an audit, or a breach, being able to show that security was considered at the beginning may be just what is needed to mitigate or reduce the penalties imposed to the organization.

There is some wiggle room for organizations within this requirement. GDPR includes the following statement, “Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity…” There is a tremendous degree of latitude or interpretation in those terms, and the inclusion of cost (with no firm definition of what is included, such as staff additions) provides some flexibility. However, this flexibility further elevates the importance of documented proof of compliance. Showing that the business evaluated security early and the fix was cost prohibitive may be a critical business document.

Looking at People, Process, and Technology as the levers, how should organizations address these challenges?

Changing behavior and asking the right questions is critical to meeting this requirement. Privacy by design and default must be considered from the start of a project or product development to be implemented effectively.
Architecting data protection at the earliest possible stage requires asking questions about your data protection needs and practices from day one and making security part of the business culture.
Once designed and implemented, data protection must be made into a repeatable process incorporated into the business rhythm. The infosec team will need to be part of the change, ensuring that all functions that touch GDPR-protected data know that it is their responsibility to protect it, but the rest of the business will need to embrace these changes as well. Given the year lead time until GDPR, this is a requirement businesses should start working on today.
As with any change, communicate, communicate, communicate. And then communicate again. Yes, it will feel artificial at first, but making lasting changes in the business requires a clear explanation of what is needed and why it is important.
Finally, from the technology side, there needs to be a way to flag and protect GDPR data as soon as it is created or collected. This default-on protection ensures that sensitive data is always protected; there is no on/off button. Once GDPR data is discovered, it is automatically tagged as such. Subsequent attempts to move it would automatically trigger alerts or controls such as encryption. This automation reduces the likelihood of making a GDPR compliance mistake.

The Privacy by Design & Default requirement in GDPR puts the need to secure sensitive data where it likely should have been, as an upfront component and not an afterthought. To learn more about the other top GDPR challenges and the steps required to address them ahead of the May 2018 GDPR deadline, watch our webinar on demand.