Businesses ask us two questions more than any others: what does testing cost, and how often should we do it. This guide answers the second one honestly, because the honest answer is not a number.
There is no single correct frequency. There is a correct way to think about it, and once you have that, the cadence picks itself.
Is there a standard answer, like once a year?
Once a year is the answer people expect, because that is how compliance cycles work: annual audits, annual reports, annual everything.
It is not a bad default. But it is a default, not a rule. An application that processes payments every day and ships new features every month is a different proposition from a brochure website that changes once a year. Treating them the same either wastes money or leaves gaps.
Before launch, and after major changes
The two moments nobody argues about. Before you launch something new, test it: a new website, a new app, a new payment flow. You do not want your customers, or an attacker, to be the first people to find a weakness.
And after major changes. A redesign, a new feature, a new third-party integration: each one rewires how your application behaves, and some rewiring opens doors the developers never meant to open.
How often does a small business need it, versus a bigger one?
Size matters less than exposure. A small trading firm with an online store and a payment gateway has more to lose than a large company whose website is purely informational.
Ask what an attacker could actually reach: customer data, money movement, anything that would force you to explain yourself to customers. The more of that there is, the more often testing earns its cost.
What if nothing has changed since last time?
Then your code is the same, but the world around it has moved. New weaknesses are published constantly. The software your application runs on gets updated by other people, and those updates sometimes open new doors.
Nothing changing in your code is not the same as nothing changing in your risk. It just means a lighter test may be enough: a fresh assessment, rather than a full deep test.
How do you pick a cadence without overspending?
Map your moments, not your calendar. Test before launch, after major changes, and when something outside changes: a new regulation, a new client contract, a new system you connected to.
Between moments, a lighter check keeps the signal fresh without paying for full depth every time. That is the practical middle: the deep test when the risk changes, the health check in between.
What actually happens if you skip a year?
Usually nothing. That is what makes skipping easy, and that is what makes it dangerous. The weaknesses do not announce themselves. They sit quietly until someone finds them.
The businesses we meet after something went wrong tend to describe the same pattern: everything was fine for years, right up until it was not. The cost of the test they skipped is a fraction of the cost of the week they did not skip.
Pick the moments, not a date. Launch, major change, new exposure: test those. In between, keep a light check running. If you are not sure where your moments are, a short conversation will sort it out.