“How often should we actually be having a pentest done?” is one of the most common questions we get, and the honest answer is: it depends on more than just the calendar. A fixed annual rhythm is a good starting point, but the right frequency is determined by a combination of compliance requirements, how often your systems change, and how much risk an unnoticed vulnerability represents for your organisation.

The compliance minimum: a floor, not a ceiling

Different frameworks set different minimum frequencies:

PCI DSS 4.0: at least annually, plus a retest after every significant change to infrastructure or applications within the cardholder data environment.
NIS2: doesn’t prescribe an exact frequency, but requires organisations to keep risk management measures “appropriate” to the threat landscape, which in practice comes down to testing at least annually for most medium and large organisations.
ISO 27001: requires periodic technical assessments; most auditors expect an annual pentest as part of the risk management process.
DORA (financial sector): at least annual basic tests, with an additional three-yearly TLPT obligation for significant institutions.

These minimum frequencies are a compliance floor, not tailored security advice. Meeting the letter of the requirement isn’t the same as actually staying secure between test moments.

What your pace of change says about how often you should test

An organisation that changes something about its infrastructure a few times a year faces a different reality than a software company deploying to production weekly. Every substantial change — a new feature, a new integration, a migration to a different cloud environment — can introduce new vulnerabilities that only come to light at the next test. Rule of thumb: the faster you change, the shorter the gap between “something breaks” and “you know it’s broken” should be.

Risk profile outweighs sector average

An organisation that processes a lot of personal data, financial data or health data, or that’s an attractive target because of brand recognition or a public role, would do well to sit above the compliance minimum. That doesn’t necessarily mean a full pentest more often, but often a combination: an annual in-depth test, supplemented with continuous or periodic vulnerability scans that catch new, known vulnerabilities faster than an annual cycle would.

A practical rhythm that works for most SME organisations

One thorough external pentest per year on core applications and infrastructure.
A targeted retest or partial-scope test after every major release or architectural change.
Ongoing or monthly vulnerability scans between pentests, as an early warning.
An internal pentest (for example on Active Directory) at least every two years, more often if the internal network changes significantly.

What testing too often can also mean

The reverse also happens: organisations that have a full, expensive pentest carried out every year on systems that barely change in between, while a large part of the budget would be better spent actually fixing earlier findings or on continuous monitoring. Testing for the sake of testing, without the frequency matching the pace of change or risk, is rarely the best use of a security budget. So the question isn’t just “how often”, but also “which type of test fits which risk best”.

How MonkeysICT helps you think through the right frequency

We never default to recommending “as often as possible” — instead, we look together at your compliance obligations, release pace and risk profile to arrive at a realistic, manageable testing rhythm. That avoids two extremes: testing too little and carrying structural risk, or testing too much without it delivering extra insight.