When a good time pentest

Doing a pentest might be in your objectives… but it’s not the right time for now. This can be for various reasons: developments are in progress, or a migration is planned, or you don’t have a budget yet…
Considering the different priorities that must be respected, when is a good moment to do a penetration test?
We are going to see together different situations in which the question arises and we’ll give you the keys to choose if it is the right moment to run a pen test.

You are in the middle of developing, you are waiting for a stabilise version before testing the security

For a project currently being coded, it is indeed interesting to wait until a first version is more or less stabilised to carry out a security audit.

But in some cases, especially in projects where a large coding phase is planned, it may be useful to conduct tests along the way, as soon as some core features are ready. This allows you to check some of the work already done in order to build on a healthy foundation. It also helps to guide the next development, in order to avoid making some errors again and to limit the time to spend later on security corrections that could delay the production launch.

For smaller projects, a pentest can be planned only at the end of the development phase. 

You have a migration server project

In general, it is more useful to test the new server configuration, when it is set up, than to test a configuration that soon won’t be used any more. However, the risks on the existing infrastructure have to be taken into account: when will the migration be done? In the meantime, what is the level of risk exposure?

The answers you provide to these questions will decide the right time in your situation.

It is good to know that in the case of a web application pentest, there are two phases: a test phase on the application layer and a test phase on the servers. It is possible to do these two phases at different times, in order to test now the application if there is a short-term need and the servers later when the migration is completed.

It should also be noted that for this type of pentest, the server testing phase represents only a small (but critical) part of the total volume of tests to be planned.

You are planning to rebuild your application

In case the old version of the application will be abandoned, the first thought is that it is not relevant to test its security. But this deserves to be considered closely: what is the criticality level of the application? What is the deadline for the refactoring? 

For cost reasons, it is often not possible to carry out an in-depth pentest on the old version of an application being rebuilt.

Doing a quick pen test on the old version is a possibility in order to get security feedback, which will allow correcting the most “obvious” flaws (from an attacker’s point of view), and which can also guide new developments (by making developers aware of certain security issues). 

It will always be important to conduct a security audit on the new version of the application, if it becomes the main application for users. In some cases, having first done a small pentest on the old version will also limit the time to spend fixing flaws on the new version, because of the transferred security skills that will have been done.

You don’t have the budget

Budget is a factor that often hinders penetration test projects, for entirely understandable reasons. However, beware of the a priori that any pentest necessarily requires a budget of at least 10k€. In reality, it all depends on the scope and the level of depth expected for the tests. 

Some customers choose to start with a mini-audit to respect a very limited budget (for less than €1500 for example) and to obtain a first feedback on the level of security found.

This allows obtaining a first indicator, depending on the vulnerabilities that would be found with very reduced time means.

This is particularly relevant for young startups, who would like to start setting up security tests with a very reduced budget, then gradually increase the means according to their growth and their level of exposure to risks. 

You don’t have time, the team is focused on other priorities (currently developing)

It is understandable not to want to add missions to the team, but be aware of the priorities that often go to the projects to be delivered and which always push security a little later. Not postponing the pentest too much to do it “when it is the right moment” (which sometimes never happens) allows not to ignore potential critical flaws.

In itself, the audit does not involve the dev team much. Pentesters are relatively autonomous to conduct the security audit. In some cases, they will need you to provide them with a test environment or even test accounts beforehand.
After the pentest, depending on the vulnerabilities identified and the corrections needed, it might require some time for the dev team. But you will be free to prioritise the remediation to be implemented, for example to fix critical flaws first, and integrate the other remediation in your roadmap.

You want to first correct the security flaws that you already know

By fixing vulnerabilities you have already identified before conducting a pentest, pentesters won’t “waste” time on known vulnerabilities and can focus on finding other vulnerabilities. 

In these situations where vulnerabilities are known, however, we have seen a trap: pushing back the pentest for a long time (sometimes months, sometimes more) to allow developers to fix the vulnerabilities. Sometimes this situation is lasting, because other priorities are set, because unexpected events have occurred, or because corrections are not 100% finalised. 

In the meantime, there may be risks related to unidentified vulnerabilities, or to vulnerabilities that have been identified but whose impact is minimised. The penetration test allows an external view, with a prioritisation of the flaws by criticality level. It doesn’t matter if we find flaws that you already know about, the important thing is to provide you with visibility on all the flaws that we have been able to find, on what their impacts and criticality levels are, and how to remedy them. You will then be able to decide on the order of priorities.

You first want to finish the correction following the previous pentest

Indeed, if you wish to deepen the tests on an already pentested area, by finishing the correction of a previous security audit, the pentesters will be able to go further in their research during the next one. They will also be able to check that the remediation implemented has not created any undesirable effects on other elements.

In other situations, for example, if you want to test another target, then the pentest can be conducted independently of the remediation in progress.

You first want to get your first clients to finance the pentest

Sometimes the budget for a pentest is only allocated if a certain sales amount is reached or if an end customer finances it. This postpones the audit to an uncertain time. 

However, customers are increasingly aware of the importance of the security of their data, following the numerous data leaks or cyberattacks that make the headlines. Being able to provide proof of security when talking to prospects can help to win new customers, which will help to achieve business objectives.

Strengthening security becomes then an investment to win new business, not an expense. To go further on this point, we give you four keys which shows the return on investment of a security audit.

You are starting a certification process (ISO 27001), you will do the pentest in a second time

If you have just started a certification process, it is possible that you will first be focused on other topics, such as risk analysis, protection reinforcement and process documentation… The pentest will come next, unless there is a particular urgency on your side, and in this case it is always possible to carry out several actions in parallel. 

The pentest confronts the security analysis with the real threat, which is usually done in a second step, even if it is not an absolute rule. Carrying out a black box pentest, with a limited time to attack different information system entry points, can also be a good start before tackling in-depth analysis and protection reinforcement work.

You are not exposed to attack risks for the moment, you will invest in security a bit later.

It is true that some activities are more exposed than others to cyberattacks that target them on purpose, for various reasons (types of data processed, expected financial gains…). 

However, not all cyberattacks are targeted. Some bots scan the web on a large scale to find vulnerabilities, especially on servers or CMS. And, of course, there are mass phishing campaigns, for scams or to spread malware. It is therefore important to protect yourself a minimum against the main risks.

Testing and strengthening your security in a period when you are not very exposed allows you to build a healthy foundation, without waiting for the period to become critical, knowing that the investment will be less important if you are facing a non-critical level of risk.

For the moment, our customers don’t ask us to do pentests, maybe this will come later

Doing a pentest before your customers demand it would show that you are proactive on the safety topic. This would make it an argument in your favour to create a relationship of trust with your customers and partners, and to differentiate yourself from your competitors. Security then creates value to encourage sales.

On another note, it is always less complicated not to act in a hurry, and not to wait to be in a blocked sales process while waiting to be able to show a security audit report. A minimum of anticipation is advised, depending on the profile and potential requirements of your prospects.

After having seen these different situations, we are convinced that you have the keys to evaluate your situation and to decide strategically when is the most relevant moment for you to do a pentest.
We are also available to a quick assessment of your situation.