Privacy by design means that developers should consider privacy at the very start of any development cycle and continue to test and review the safeguards that they afford to their data subjects as part of the iterative development cycle.
Privacy by default means that whenever a system or service includes choices for the individual on how much personal data he or she shares with others, the default settings should be the most privacy-friendly ones. Under the previous Directive (pre GDPR), data controllers were simply required to implement appropriate technical and organisational measures to ensure that personal data was protected against unlawful processing. All too often though, privacy considerations were sat on the back-burner and perhaps introduced at final stages. Under GDPR organisations must consider privacy at the earliest stage. Privacy must be ‘baked-in’ to any new product or service, rather than sprinkled on at the end like hundreds and thousands on a cup cake. A Data Protection Impact Assessment (DPIA) will document the personal data that will be processed by the system and record the legitimate and legal basis upon which it is processed. This will reduce the risk of discovering, at a later stage, that it is too technologically challenging or not even commercially viable to continue the development due to cost. Under the GDPR, organisations will not only be responsible for adhering to privacy principles, they must be able to demonstrate compliance with them too because the GDPR revolves around the principles of accountability.
Applying the concept of Privacy by Design will typically make the development process more efficient because it will be clear from the outset what data processing activities will take place. It will provide an opportunity to give data subjects a choice about how their data is used by applying Privacy by Default. This, in turn, will lead to the key principle of processing data transparently.
The ICO has published this checklist which forms the basis of Data Protection by Design and Default. It should be uppermost in the mind of any developer starting a new project in the GDPR age.
We consider data protection issues as part of the design and implementation of systems, services, products and business practices.We make data protection an essential component of the core functionality of our processing systems and services.
- We anticipate risks and privacy-invasive events before they occur, and take steps to prevent harm to individuals.
- We only process the personal data that we need for our purposes(s), and that we only use the data for those purposes.
- We ensure that personal data is automatically protected in any IT system, service, product, and/or business practice, so that individuals should not have to take any specific action to protect their privacy.
- We provide the identity and contact information of those responsible for data protection both within our organisation and to individuals.
- We adopt a ‘plain language’ policy for any public documents so that individuals easily understand what we are doing with their personal data.
- We provide individuals with tools so they can determine how we are using their personal data, and whether our policies are being properly enforced.
- We offer strong privacy defaults, user-friendly options and controls, and respect user preferences.
- We only use data processors that provide sufficient guarantees of their technical and organisational measures for data protection by design.When we use other systems, services or products in our processing activities, we make sure that we only use those whose designers and manufacturers take data protection issues into account.
- We use privacy-enhancing technologies (PETs) to assist us in complying with our data protection by design obligations.
It is essential to address communication with data subjects at the initial design stages of any project and to continue to incorporate this throughout the complete development process. Data subjects must be clear about how they can expect their personal information to be processed and understand how they can exercise their rights as a data subject (which are substantially ‘beefed up’ under GDPR).
Any development project will need to map its data flows. This means understanding and reporting upon the data that is being collected, where it’s being collected, what happens to it and who has access to it. Under GDPR companies will be required to provide a detailed history of every step a piece of information makes within their organisation. This means developers will need to track their client’s data, know who has access to it and how the data is used to meet the required standard.
It is equally important to think about how the data will be protected and GDPR advocates the use of encryption and pseudonymisation to achieve this. Data retention schedules are also a major consideration as are the ability to easily amend and delete data and provide it to a data subject in an easily portable format (such as CSV).
The successful implementation of system based privacy requires that individuals – involved in the development of new products and services are sufficiently conversant with the concepts of data protection. The actual development methodologies (Agile, DSDM, LD etc.) used within the organisation must be taken into account in order to apply the concepts coherently throughout the entire development process. Finally, once a system has been developed through to go live, it must be continually reviewed, tested, adapted and monitored by the organisation throughout its lifetime. The reality is that developers must adopt a ‘cradle to grave’ approach to data protection, privacy and information security for any process or system in use within an organisation.
For systems developers these concepts provide an opportunity to increase efficiency, reduce costs, gain data subjects’ trust and enhance corporate reputation.