Penetration Testing: how often should you test?

The truth is, it’s very unlikely you’ll even get a strong answer from an organisation as to how frequently you should test. Even organisations like the NCSC, who offer guidance to UK businesses on how to stay secure, don’t give a direct answer to the question. However, they may comment on other businesses behaviour such as saying “it’s not uncommon for a year or more to elapse between penetration tests” before commenting that this is likely insufficient.

Other companies may say testing should be conducted “at least annually” which again, doesn’t really give you a strong indication on how frequently you should be testing – aside from the fact that you should do it at least once for every lap of the sun our planet makes.

So, let’s dig in to how to work out what testing frequency is right for your business. Penetration testing is a point in time assessment that will give you a very strong understanding of how vulnerable your systems are to known security issues on the day of the assessment. However, as systems are updated, configurations are changed, and IT projects are undertaken – your network as it looks today starts looking less and less like it did on the day of the assessment.

Therefore, if you’re not changing your systems very frequently, or if you’re a software company – you’re not releasing new versions of your software very often, then a slower testing cycle might be appropriate for your business. Perhaps once per year for a relatively static company is just about right.

But, if you’re releasing software with an agile lifecycle, or constantly improving your IT networks with new systems and features – then you need to be testing more frequently. It could be that a full assessment is needed twice per year, or even quarterly.

However, just performing “full assessments” at this frequency might be somewhat inefficient. For example, a more intelligent approach could be to do a full “baseline” assessment once per year and then do change-based “on-going” assessments throughout the year. This could track your software release cycle, or it could be a smaller assessment after any major system change – such as the installation of a new firewall or major software rollout, to focus on the aspects of the system that have changed.

In short, tying your security testing cycle to an arbitrary fixed cycle is ineffective – instead you should tie your testing schedule to the work your technical teams are conducting to ensure that any major change does not negatively impact your organisation’s security stance.

However, there’s one additional “gotcha” for companies that make continuous small changes. If you’re an agile company that’s constantly tweaking things and making small changes, you might find there you rarely have a “major change” to trigger an additional penetration test. So it’s worth continuously reviewing your recent work to ensure that once enough work has been conducted such that your previous test is no longer representative of your current system – it’s time to book another penetration test.

Whether that needs to be another full assessment or if it can be a smaller assessment based around the changes will depends on how significantly your systems have changed. Smaller changes can likely be covered by a smaller, more focused, assessment – saving your budget whilst still delivering security.

If you’d like more guidance on how this applies to your company, get in touch and we’ll guide you through how to develop a testing strategy.

References

• NCSC: Penetration Testing