Go back to overview

Security Explained: Penetration Testing Models

3 June 2021

When it comes to penetration testing, there are multiple avenues of engagement. Traditionally, there are three models that would be used. In a continued effort to take some of the mysticism and confusion out of the topic, we’d like to lay these three out plainly.

Penetration Testing Engagement

When someone needs to go about getting their application or system’s security checked, you would typically engage with penetration testing. To learn more about the topic, we have articles such as penetration testing and vulnerability scanning and more on the testing packages we offer.

Once you settle on a security firm to collaborate with, you would then agree on a type of engagement. The three we’ll be covering are, project-based, retainer testing, and SDLC (Software Development Life Cycle) integrated. While these are just different types of engagement for penetration testing, they can almost be listed as a traditional escalation of service. We’ll explain a bit more as we get into each of the models.


This is absolutely the most common when starting penetration testing, whether entirely or with a new security team. Project-based is engagement-based entirely on a project-to-project basis. With each engagement, there is a proposal created. These are based on the assets and functionalities in need of testing and the type of testing package, which includes black, grey, or white box testing.

This is an easy entry-level model, as it is a quick and accessible choice in the short term. However, in the long term, it can begin to slow down. This is due to the requirements of a proposal and quote for each and every project. This naturally results in quite a lot of paperwork and admin for what is effectively just a recurring partnership.

Nonetheless, it is an excellent entry into discovering collaboration opportunities. It is the stage for benchmarking not just the technical skills of a security team but also their communication skills.

Retainer Testing

This one is a continuous and repeated engagement between client and security, as if on retainer. The security team engage with the client on a repeated, predefined basis. For example, the security team test two weeks out of every month. The paperwork is worked out as one big proposal, for this ongoing security collaboration.

Recurring testing offers a number of benefits. It’s a strong collaborative effort, as each recurring test requires the assets and functionalities to be determined. The security team will quickly gain an understanding of critical assets, key functionalities, and the IT infrastructure. This means testing will quickly gain and maintain a speedy efficiency throughout the engagement. For those requiring a longer or repeated testing period, this is a much more cost-effective model and qualitative model.

SDLC Integration

As mentioned above, this stands for software development life cycle. Integration on this level is an incredibly close collaboration between security and technical team.

The software development cycle is split into sprints. Assets and functionalities are pushed out in each of these sprints. Naturally, being involved and directly integrated into this life cycle is hugely beneficial. We test the moment the development is finished. If we find any issues, there’s no big update to roll back. Any vulnerabilities can be immediately picked up and patched before the thought of release occurs.

This model is typically used with software that have regular or seasonal updates. With such an early integration of security, we can aid in an efficient security architecture. This type of collaboration allows us to aid in developing an app or game that has security by design.


Each of these models are an escalation of the previous, resulting in a much tighter collaborative effort. In terms of effectiveness, both cost and time, we prefer the second two models. With resources allocated and predetermined targets, penetration testing can be conducted much faster and with a greater level of safety for the client. Of course, being integrated with the very development process is a security engineer’s dream. Allowing us to offer the assurance of high-quality security rather than a post-release patch.

If you’d like to learn more about penetration testing, you can contact us or visit our pages on application and game testing.