Data protection by design

What is data protection by design?

Article 25 of  General Data Protection Regulation (GDPR) mandates ‘data protection by design and by default’. When developing software this includes ensuring favourable privacy settings are enabled by default. In security terms, it means implementing a secure software development life-cycle that builds in security and data protection from the ground up and is not ‘bolted on’ as an afterthought. If you would like to learn more about how cyber security links with data protection practices, we recently published a helpful article that talks about the Importance of Cyber Security in Data Protection and the UK GDPR. 

Software developers are under immense pressure to write and launch code at speed in order to be competitive. However, speed can come at the expense of data protection and information security if not managed carefully. Security and privacy by design are key concepts to address during the software development life-cycle. 

When developing software, it might be tempting to ‘launch now, patch later’ to monetise your hard work, but there really is no benefit in releasing software that simply isn’t secure. The reputational damage associated with a security incident should be reason enough to develop secure software but if that still doesn’t convince you, you can now add compliance penalties and legal costs to the mix if your application processes personal data.  

But you shouldn’t just do something because you have to, you should do it because it’s the best way. Who doesn’t want their application to be secure? So now we’ve had that pep talk, what is a secure software development life-cycle (SSDLC) and how can you implement security and privacy by design throughout it? 

What is a Secure Software Development Life-cycle (SSDLC)?

An SSDLC provides a framework for developers to ensure tasks get carried out at each stage, this prevents actions being missed and enables the process to be repeated where necessary. Irrespective of whether you follow a traditional Waterfall methodology or a more modern Agile development methodology, your development life cycle will include:  

1. Planning & requirement analysis
2. Defining requirements
3. Designing the product architecture
4. Building or developing the product
5. Testing the product (including security testing)
6. Deployment in the market and maintenance 

We’ll address each of these in turn. 

Planning and requirement analysis

This is the foundation of your life cycle. If a poor plan is put together, important areas can easily be missed. The planning stage requires everyone involved in the software development from the owners of the products, customers, developers, architects, and testers. Team leaders must be involved and importantly, so must your Data Protection Officer (DPO) and Information Security Officer (CISO) if you have them. To incorporate security and privacy by design from the beginning, it’s important to determine what requirements should be set for the software, such as what laws and guidelines are to be followed. The following items need to be discussed at this early stage: 

• What categories of data and personal data will be processed in the software? 
• What conclusions can be drawn about individuals based on the data being processed? 
• If applicable, who is the data processor or recipient of the personal data? 

The ICO Children’s Code

If you are designing software or a product aimed at children or teenagers, it is also imperative that you understand your obligations regarding the ICO Children’s Code which came into force in September of 2020 and is a requirement under the Data Protection Act 2018. Notably, the Code applies to services that are likely to be accessed by children, not just those specifically targeting them.

The Code takes the form of 15 “flexible” standards and includes principles such as; the best interests of the child, parental controls, default settings, DPIAs and transparency to name a few. To read more, our article The ICO’s Age-Appropriate Design Code outlines these in more detail. You may also find it interesting to read about the more recent TikTok GDPR fine, imposed by the DPC, as a result of finding them to have mishandled children’s data.

Defining requirements

This involves putting documentation in place to cover the requirements needed by the customer and/or business. Security and data protection requirements should be: 

• Crafted into a checklist 
• Integrated into the project plan  
• Monitored throughout the entire development process 

Designing the product architecture

This is the phase where the attack surface is analysed, and vulnerabilities are designed out of the software. First, the architecture should be mapped out, this enables you to determine what data flows throughout the product, where it flows, and how.  Visualising the data flow enables you to identify vulnerabilities or potential areas that could be exploited. 

A key part of this process is reviewing the Open Web Application Security Project’s (OWASP) list of common vulnerabilities and addressing them. The DPO, CISO, developers and software architects should work together to list what vulnerabilities could exist and ensure that mitigating procedures are put in place to prevent or reduce the likelihood of vulnerabilities being exploited.  

There are several different methods available for carrying out an Attack Surface Review.  Microsoft has their own called STRIDE, which Stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of privilege which is used to assess and classify threats the product will face. When armed with a list of threats that could apply to the product, you should:   

• Work through the list in sequence. 
• Classify each threat against one of the 6 STRIDE categories. 
• Assign a mitigation strategy to each one (where possible).  
• Break down the threats by assigning them a threat rating.
• Treat the highest-rated threats and work down the list. 

Building or developing the product

This is the stage when planning and design come together. Developers, the DPO, CISO and testers should work together to ensure that everything discussed and documented in the previous stages, including the requirements for data protection and information security, is realised. This is when you define and document a list of approved tools, processes and frameworks for software development and roll-out. It’s important here to establish and implement: 

• An automated code analysis tool. 
• Procedures for static code analysis. 
• Procedures for code review. 

Testing the product

This should occur iteratively throughout the development process and once the product is ready to be released. It involves two aspects; checking the software generally functions as required and ensuring that data protection and information security requirements have been implemented and are functioning as required. The DPO, CISO, developers and project leaders should carry out testing in a separate environment, away from live networks to prevent disruption or damage to live systems. Testing for vulnerabilities involves: 

• Dynamic testing – ensuring users can only access the information and functionality they are authorised to. 
• Fuzz testing – Intentionally triggering errors in software.  
• Penetration testing – using white hat hackers to test the security of the software. 

Deployment in the market and maintenance

This is the final phase where the product is released for customer use. This can be done all at once or in stages depending on the required methodology agreed upon in the planning stage. Maintenance is required to ensure the product remains as secure as possible to exploitation. Examples of maintenance procedures include; 

• Regular security testing. 
• Continuous vulnerability analysis. 
• Ongoing penetration testing of software, infrastructure and network.  
• Error debugging. 
• Performance improvements.
• Updates and patching, of the software and third-party components.  

Conduct regular external and internal audits to document compliance with relevant regulations.  

Security incidents are likely to happen, even if you’ve followed a mature SSDLC. You therefore also need an incident response plan in place – so you know what to do if your application suffers a security breach. Have a written incident response plan with roles and responsibilities designated in advance, so you can react quickly to mitigate the risks. 

To learn more, download your free

Guide to Incident Response 

Keep testing

It’s surprisingly common for security testing only to be carried out at stage 5, the ‘Testing the product’ phase, but this is a fundamental mistake. If a weakness is discovered at this late stage, are you really going to start from scratch? According to the IBM System Science Institute, defects found in testing were fifteen times more costly than if they were found during the design phase. If, due to time and cost, software is launched with known vulnerabilities, it is two times more costly to fix than if discovered during deployment. Learn about threat modelling and why you shouldn’t build anything without it. 

Need help?

If you are unsure if your software development methodology is encompassing security and privacy by design, we can help. Our consultancy services will establish how well you are managing privacy by design into your software development life-cycle.