Privacy by Design is a concept which can be found at article 25 GDPR and was created in the 1990s by Dr. Ann Cavoukian, former Information and Privacy Commissioner for the Province of Ontario, Canada.
The concept is known to refer to 7 foundational principles:
Related article: GDPR FAQ
Disclaimer: This blog article was written by our compliance experts for general information and does not claim to provide legal advice. To understand the full context of your organization, please consult with a privacy compliance and/or legal professional.
The GDPR imposes Privacy by Design and privacy as the default setting to all controllers.
This does not translate in a to do list for the controller. Instead, the controller is expected to implement “appropriate” technical and organizational measures that are designed to implement data protection principles in an effective manner and to ensure that, by default, only personal data is processed that is necessary for each specific purpose of the processing . This, of course, applies to the amount of personal data collected, the extent of the processing, the period of the storage and accessibility.
The GDPR does not give a clear answer. It states that the decision must depend on the state of the art, the cost of implementation, the nature, scope, context and purposes of processing, all of which must be balanced against the risks of varying likelihood and severity for rights and freedoms of natural persons posed by processing. This risk analysis must occur at two moments: (1) at the time of determining the means of processing, and (2) at the time of processing.
In the case of software design, for instance, this translates into 5 phases:
During the planning phase, developers are expected to plan for organizational and security measures that will allow the software to present an acceptable risk level for the rights and freedoms of data subjects.
Then, in the testing phase, developers are expected to conduct technical testing such as vulnerability assessment and penetration testing to ensure that the initially agreed upon measures continue to be sufficient and that there is no change.
Even after deployment, at the management phase, software must be audited and tested to guarantee that the risk level has not changed, for example by new vectors of attacks that may emerge as technology evolves.
It’s not enough to say “my software is compliant” and then sit back and relax. You will have to do a compliance audit every year – sometimes more often depending on whether it is high-risk processing or not. You will have to continue testing, auditing and ensuring that the risk level has not changed because the threat landscape will evolve.
In any case, you should be able to do web application testing or software testing with a GDPR flavor.
Privacy by Design is just one of the many aspect of GDPR that requires compliance officers to conduct a risk assessment prior to taking decisions on privacy.
The whole GDPR takes a risk-based approach. All parts of GDPR compliance also require considering the risk to the rights and freedom to individuals, so you should start by mitigating the risk for projects which you consider to be of highest risk. GDPR refers to appropriate technical and organizational measures, but what is appropriate will largely depend on the size of the organization, the type of data that is processed and the purpose of data processing.
For example, a manufacturing company has mainly HR-based apps and some data of visitors who are physically accessing its premises. This, of course, has a different risk level than a medical services company that is mainly dealing with patient data.
The manufacturer will likely focus on the compliance processing of their HR data, and make sure that employees can verify their data, maybe consult with unions and employee representation. The medical services company, in turn, will need to focus on their patients because the data is much riskier.
If we were to work with a client one day who wakes up the next morning and says “prior to doing this, let me see what would be the risk to data privacy”, we would have accomplished a huge change in mindset by thinking about data privacy at the beginning rather than at the end of the process. It’s certainly a mindset to integrate privacy as a component of everything you’re doing.
Once you start doing this, it’s all about documenting. You will find yourself able to meet other requirements quite easily.
In the context of GDPR, an unacceptable risk is one that results in a threat to or loss of rights and freedoms for the individuals, which cannot be mitigated through the implementation of effective controls and/or that is unreasonable in relation to the intended benefits.
