,

Embedding GDPR in the secure development lifecycle (SDLC)

Secure Development Lifecycle en GDPR

Did you know that the GDPR and SDLC re-inforce each other and that the GDPR can be used as the ideal business case to start with SDLC? Siebe and I explained how and why during the OWASP AppSec Europe conference in Belfast. Couldn’t attend? You can find the presentation in our previous blog, or begin by reading the introduction below.

We all know that in less than a year the GDPR (General Data Protection Regulation) enters into force to unify the privacy legislation within Europe and the UK and improve the protection of personal data and data subject rights. And I don’t need to tell you that the secure development lifecycle (SDLC) method is thé go to methodology when planning for, designing, building, testing and delivering information systems. But if you play it smart, you can improve your SDLC by including GDPR activities and use SDLC artifacts to demonstrate compliance with GDPR.

A lot of articles in the GDPR specifically refer to security. Article 25 for instance, on privacy by design & default, article 32 on Security of Processing and article 35 on DPIA’s all specifically mention the security levels and assessments that should be considered. The most efficient way to comply with these GDPR security requirements when developing (new) applications, is by integrating them into your Secure Development Lifecycle.

You can find more information on the OWASP Software Assurance Maturity Model (SAMM) and how it can be integrated into any existing SDLC here. For now, it suffices if you know that OpenSAMM is defined in different levels.

  • At the highest level it is divided into four tasks or concerns to consider while developing or using software. They align well with a typical organisational structure, and this is how software security typically ties into an organisation.
  • At a lower level, several security practices are defined that should be considered for improving software security.
  • At the lowest level, every security practice consists of a set of activities, ordered in maturity levels or objectives.

The GDPR articles related to security fall perfectly into these activities. Just check out this table:

SAMM domains

 

So, when you divide for example the GDPR requirements on Policy & Compliance into three objective levels, this is the result:

PolicyCompliance

More examples and details can be found in the presentation in our previous blog. Or get in touch!

 

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *