What counts as a significant change?

Anything that changes your attack surface or how data and funds flow: new features that handle money or personal data, new authentication methods, new infrastructure or cloud accounts, new third-party integrations, and major framework upgrades.

Do compliance frameworks set a frequency?

PCI DSS requires internal and external testing at least every 12 months and after significant changes. DORA requires systems supporting critical or important functions to be tested at least yearly. SOC 2 and ISO 27001 leave it to your risk assessment, and annual testing is the usual expectation.

How Often Should You Do a Penetration Test?

How often should you do a penetration test?

At least once a year, and again after any significant change: a major release, new infrastructure, a new integration or a change to how you handle sensitive data. Systems that change weekly or hold high value, such as exchanges and DeFi front ends, benefit from testing more often or continuously alongside development.

A sensible baseline

Situation	Suggested testing
Stable system, low change	At least annually
Regular releases	Annually, plus after significant changes
Holds funds or high-value data	Twice a year or more, plus after significant changes
Exchanges, custodians, DeFi front ends	Ongoing testing alongside development, with periodic full tests

Why once is not enough

A penetration test reflects the system on the days it was tested. New code, new dependencies and new infrastructure all add risk, and new attack techniques appear against old code too. Security is ongoing, and we recommend regular testing cycles that account for code changes, new infrastructure and new threats.

Pair testing with the rest of your programme

Testing frequency matters less if fixes do not happen. Track findings to closure, retest them, and feed what you learn back into development. For systems handling large balances, add a red team exercise to check that monitoring and response would catch an attacker between tests.