Logo and page links

Main menu


Software development with Data Protection by Design and by Default

Testing

During this activity, testers check that the requirements for data protection and information security defined during the Requirements and Design activities have been implemented as planned, as well as verify that the requirements have been properly met.

The software must also be tested for vulnerabilities. This is done using dynamic testing, fuzz testing, and penetration testing. It is important to review the attack surface to verify that attack vectors uncovered during the Design activity, and potential new attack vectors introduced during coding, are handled.

The target audience for this activity is primarily testers. Data protection officers and security advisors, developers, and project leaders may also be involved in testing.

Test that requirements for data protection and security have been implemented

Tests should be carried out to ensure that requirements for data protection and security are met through design and coding, and that the requirements have been correctly implemented within the software. The checklist prepared during the Requirements activity should be used to verify that all components required to meet the requirements are included in the software. The verification should, where applicable, include new components introduced later in the development process, during design and coding. For testing, synthetic personal data should be used.

Security testing

Security testing involves comprehensive testing of the software to discover vulnerabilities and to ensure that the code adequately safeguards security and data protection. We recommend establishing procedures for automatic execution of test sets, which should be run each time software is built.

Dynamic testing

Test functionality in running code by using tools or manual reviews to analyse how the software behaves in relation to different user permissions and in the cases of critical security failures. The testing will ensure that users only have access to the information and functionality that they are authorised for. It is important to verify that attempts to gain unauthorised information are logged as security breaches. Examples of known vulnerabilities that should be investigated while running the software are Cross-site scripting and SQL injection. Session management, cookie use, and access control should also be tested to ensure that personal data cannot be retrieved by users who are not logged in.

Fuzz testing

This sort of testing is conducted by intentionally triggering errors in the software. This can be done using tools that send random and malformed data (incorrect input values) to all possible input fields in the software, either manually or using intelligent tools that analyse vulnerabilities in web applications. If the software has multiple interfaces, efforts should be made to test each of them. Use tools that can analyse output and apply security contexts, such as web proxies with the capacity to scan for vulnerabilities in their own software.

Penetration testing/vulnerability analysis

In order to detect vulnerabilities, penetration testing or vulnerability analysis should be carried out before release, and at regular intervals. Such a security test must be a legal and authorised attempt to find, exploit, and detect vulnerabilities. Following the test, measures to make the software more robust should be implemented. Because knowledge can be personnel-dependent, you should regularly rotate those responsible for testing. Furthermore, it is advisable to use security advisors to analyse the results.

Threat model and attack surface review

As software can differ from the functional and technical specifications defined during the Requirement and Design activities, both the threat model and the attack surface should be reviewed once the software is complete for release. This review should verify that new attack vectors that may have been introduced during coding have been identified and managed, and that the threat model is being reviewed against newly developed software. As the requirements may have changed during the development process, data protection impacts must be reviewed again. For example, verify that all personal data has a legal basis for processing, is necessary and is adequately protected.

Download