What is GDPR by Design?

Written by Keith Mason / November 19, 2018

On November 11, 2018 CBS aired a timely ‘60 Minutes’ episode which included a GDPR segment – please review the link if you missed the airing. In the segment, Mr. Schrems, an attorney in Europe, shared that he submitted a request to Facebook asking for a copy of the personal information they had about him. He received a 1,200 page PDF in return representing his casual Facebook usage over a 3 year period!

In this, and future blogs, we will bring a high-level of transparency regarding our GDPR compliance, why we collect personal information about you, how we use it, the conditions under which we may disclose it to others, how we keep it safe and secure, and your rights and choices in relation to your information. We will also provide some perspective on our software development standards and the Information Security measures we have implemented.

So, what is “GDPR by Design”?

Well, what we really mean is “Privacy by Design”.

Privacy by design, as a concept, has existed for many years, but is only now becoming part of a legal requirement with the passing and implementation of GDPR. At its core, privacy by design is essentially ‘data protection through technology design’ whereby data protection capabilities are intrinsically integrated into systems design from the onset, rather than future additions which are typically bolted-on to an application later.

With organizations preparing for and supporting the implementation of GDPR there has been a lot of focus on Employee Training, Data Subject Consent, Data Subject ‘Right to be Forgotten’, how personal information is collected, retained and shared, and the potential for fines. These are all important considerations, and ones in which we support and are in compliance with, however an area of risk for legacy systems, and one which is in danger of being overlooked for new systems, is the Design.

Data protection by design is defined in GDPR Article 25. Note the first two parts or the article below:

1. 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 for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.
2. The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual’s intervention to an indefinite number of natural persons

Article 25 states that all systems, applications, and processes in the support of collecting and processing personal information must be designed to incorporate best practices for pseudonymization (data masking)data minimization (only the minimum amount of data needed to accommodate processing is collected, and it is not to be retained beyond the scope of the need), and include technology and procedures to safeguard data while it is being processed. We completely agree and have additionally implemented safeguards to encrypt data at rest and in transit. Naturally, it is best to design the right solution from the ground up, but what about those other organizations re-engineering legacy systems?

When reengineering a legacy system, such as one pre-dating GDPR, Solution Architects and Software Engineers have the daunting task of first being able to identify where personal information resides in the database(s), what upstream systems it may be sourced from and if it is being sent to any downstream systems – this is a common practice especially in specialized services like printing, billing and mail merging activities.

Many older systems do not have Data Maps (we’ll discuss this in the next blog) depicting the flow of personal information through the system(s) (including upstream/downstream sources) and which databases, schemas, tables and columns contain the data. Additionally, it is common for older systems to have personal information stored in comments fields or in unstructured data formats which would most likely be undetected during analysis. Legacy platforms often have poorly documented or outdated Data Sharing Agreements with upstream/downstream integration partners. These integration partners may have responsibility for systems within the same organization like Sales, Marketing or Payroll systems, or they may be agreements with third-party business partners.

Some organizations were not proactive in their preparation for GDPR and if these IT shops lack Data Maps and Data Sharing Agreements they will not have full knowledge regarding personal information being sourced from upstream systems, and what downstream systems may be receiving personal information. Think about it, this would greatly misrepresent an organization’s ability to honor something as simple as a Data Subject Access request or the Right to be Forgotten. If they are not 100% certain where your personal information is stored there is no way with any level of integrity to accurately execute your request.

If the Information Commissioner’s Office investigates an organization for a possible breach of the GDPR, the investigator will ask for supporting documentation proving the policies, procedures, and the technology are deployed to ensure GDPR is being met. Imagine WordPress’ response to such an inquiry, “for the item in question, demonstrate how you ensured GDPR compliance.” Their position might be to guide the investigator to a third-party library or plug-in like the one exploited on November 9, 2018 where over 100,000 sites were exposed enabling hackers to create new users with admin permissions on sites.

We’ve built BlueberryCMS from the ground up with GDPR compliance in mind and by design; we don’t have security issues, plug-ins or patched-up applications that have been donated from an open source international community. We build everything in-house, we do not utilize any upstream/downstream integration partners and personal information never leaves the platform. With BlueberryCMS, you don’t have to gamble on a hosted solution or your customers’ personal information!

What Does GDPR by Design Mean For You?

In our next article in our series of GDPR blogs we’ll provide information about our GDPR compliance in the areas of:

• Data Map
• Data Breach/Incident Response Plan
• Data Subject Access Request
• GDPR Your Right to be Forgotten
• Lead Generation
• Data Collection, what, how and why
• GDPR Employee Security Training
• Employee Data Access

And, in other follow-up GDPR blogs (Data Protection) we’ll dive into Information Security, Cybersecurity and Threat preparation to include:

• Threat 1: Data Breaches
• Threat 2: Ransomware and Malware
• Threat 3: DDoS Attacks
• Threat 4: People
• Access Control
• Security Investment
• Static/Dynamic code Scanning