Penetration Testing: how often should you test?

It’s unlikely you will get a strong answer from most organisations 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 adding  that this is likely insufficient.

As an experienced testing company, our standpoint is clear – a minimum testing schedule should be once per year. The world of cyber security is sadly far too fast moving, and threats too quickly evolving, for anything less to work on a practical basis. However, for some companies even this might be insufficient – there are lots of variables at stake.

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 may easily be looking less and less like it did on the day of the assessment.

The opposite is also true: if you’re not changing your systems very frequently, or if you’re a software company and 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 inefficient and expensive.  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 can be 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 body of work to ensure that once enough work has been conducted such that your previous test report 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. Whether that’s a once per year test, or building a bespoke schedule to suit the needs of your company.

References

• NCSC: Penetration Testing