Embedding GDPR in the secure development lifecycle (SDLC)

Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.

SUMMARY

  • AI breaks “classic” secure-by-design: risks keep shifting after deployment due to updates, reuse, and unpredictable behavior.

  • The problem is control, not detection: a threat modeling report often leads to fragmented follow-up and unclear ownership.

  • Secure-by-design for AI must be continuous: sustained accountability, tracking, and visibility into residual risk across the full lifecycle.

  • AI-rich companies hit the wall first: scale, key-person risk, and audit pressure make one-off reviews unsustainable.

  • Toreon makes it actionable with AI threat modeling: we pinpoint AI-specific vulnerabilities as the starting point for focused mitigation and provable compliance.

Ontdek ons laatste nieuws

Embedding GDPR in the secure development lifecycle (SDLC)

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?

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.

 

More questions?

Contact us

Want to stay in the loop?

Subscribe to receive the latest news and updates.