Logo and page links

Main menu

About the guidelines

These guidelines are primary intended for developers, software architects, project managers, testers, data protection officers and security advisors. Everybody who develops and contributes to the development of software containing or processing personal data.

Software development begins with an idea of creating a product that will help to simplify or improve the quality of a process or task. There are functional requirements to how the software should solve the task.

Background

Software development should follow a methodology with key activities to ensure that the final product is robust. There is some technical literature that focuses on security by design as part of developing software. However, there is less about data protection by design and by default as part of developing software. While working on this guide, we have used Microsoft Security Development Lifecycle (SDL),  Secure Software Development LifeCycle (S-SDLC) and ENISA; Privacy and Data Protection by Design – from policy to engineering, as a starting point, and explored how to incorporate data protection principles, subject rights, and the requirements of the GDPR into every step of the process.

Seven activities in a continuous process

The circular diagram at the start of this guide contains the seven key activities in the process of developing software with data protection by design and by default. Each activity is depicted as a jigsaw piece or a step leading to the next activity in the circle. We chose a circle to illustrate because both software development and data protection are continuous processes.

This guide describes each activity in the process, alongside our recommendations on how to carry it out, and what measures we consider important to successfully comply with the requirement to build data protection by design and by default into software. However, this does not mean that each organisation must follow this process to the letter when building data protection into software. It is up to each organisation to decide which methodology to use, which measures, areas, and activities should be emphasised, and where to increase your efforts. The choice of methodology is typically influenced by the services provided, the industry, the type of software being developed, and considerations/perceptions relating to the organisation’s own level of risk.

This guide should not dictate a strict, sequential, and rigid process for each activity in the development process. It should rather be adapted into the specific methodology the organisation has chosen to use. Organisations that develop and release software at a fast pace, should consider how the guide best can be used to ensure that basic data protection and security parameters are in place, and how, for example, data protection and security tests can be included in fully automated testing regimes.

Summary of the activities

The seven activities in this guide start with training. In the section on training, we cover the most important topics on which to provide training, why, how to do this, and which tools to use.

The section on requirements describe the measures needed to ensure data protection and security, the tolerance levels the organisation should set for data protection and security, and the need to assess both security risks and data protection implications.

The next section takes these requirements further, to design, by dividing them into data oriented and process oriented design requirements. During this activity, it is important that the organisation carries out both threat modelling and an analysis of the attack surfaces.

The coding activity underlines the importance of developers using approved tools and frameworks, disabling unsafe functions and modules, and regularly carrying out static code analysis and code review.

The section on testing involves a recommendation to test whether data protection and security requirements are implemented properly, a description of what sort of security testing should be carried out, and an explanation of the importance of threat modelling and analysing the attack surface.

Before release, an incident response plan should be established, and a full security review of the software should be carried out. Release is then approved and all relevant data from the entire development process are archived.

The final activity involves the maintenance of the software and the response to incidents. The organisation should be prepared to respond to incidents, personal data breaches, faults and attacks, and be capable of issuing updates, guidelines, and information to users and those affected by the software.