Every organisation we've worked with has the same annual rhythm. Budget approves a penetration test. A window is scheduled. A team comes in, tests for two or three weeks, and produces a report. The report is impressive by weight — often a couple of hundred findings — and it gets filed, partially actioned, and forgotten until the same time next year, when the ritual repeats.

We ran engagements exactly like this for years. It's not that they're worthless; a good annual test still surfaces real problems. It's that the model quietly stopped matching how attacks actually work, and most people haven't updated the habit.

The retest that told the whole story

A few years ago we retested a client's external estate roughly ten months after the original engagement. One of the "critical" findings from the first report — a misconfigured service that gave a straightforward path inward — was back. Not a new instance. The same one. It had been remediated, signed off, closed in the tracker, and somewhere in the intervening months a routine change had reintroduced it. For nearly a year, a hole everyone believed was shut had been quietly open again.

That's the flaw in point-in-time testing in a single anecdote. A test tells you the state of your security on the days it was run. Your environment does not hold still for the other three hundred and fifty. New services get deployed, identities get provisioned, integrations get wired up, someone opens a firewall rule "temporarily." By the time next year's test comes around, the thing it's testing barely resembles the thing that was tested last time.

Three structural problems, not one

When we step back, point-in-time testing has three weaknesses baked into it, and they compound.

The first is that it ages the moment it's finished. The report describes a snapshot that starts drifting out of date the day after the testers leave.

The second is that it counts rather than proves. Two hundred findings sounds thorough, and buyers often reward the fattest report. But most of those findings are noise a scanner could have produced, and the document rarely tells you the thing you actually need: which five of these two hundred can be chained together into a real path to something that matters. We've seen boards approve remediation budgets based on severity labels that had almost nothing to do with genuine exploitability.

The third is that it stops at the report. Remediation and retesting are treated as someone else's problem, on someone else's timeline, and closure is assumed rather than confirmed. That's exactly how a "fixed" finding comes back to life for a year.

What continuous actually means

Continuous Threat Exposure Management — CTEM, if you like acronyms — is the industry's attempt to fix the calendar problem. Stripped of the marketing, it's a simple change of posture: instead of testing once and hoping, you run testing as an ongoing loop.

You continuously discover what's exposed, because your attack surface changes weekly. You validate which of those exposures are genuinely exploitable, because most aren't. You prioritise by business impact rather than raw severity, because a "medium" on a system that touches customer funds outranks a "critical" on a forgotten test box. And crucially, you remediate and retest — and you prove the fix held, rather than closing the ticket and moving on.

The difference in outcome is not subtle. Under the old model, that misconfigured service would have sat open for the better part of a year. Under a continuous one, the change that reintroduced it gets caught in the next cycle, not the next budget season.

The part that doesn't get commoditised

There's a fair objection here: aren't automated tools and, increasingly, AI going to do all this on their own? For the easy layers, yes, and good riddance — nobody senior enjoys running discovery scans. Basic enumeration is becoming a commodity, and it should.

But the value was never in finding the open port. It's in understanding how a foothold on that port becomes a breach — the chaining, the lateral movement, the abuse of an over-trusted identity, the business-logic flaw a scanner can't even conceive of. That's judgement, and it's the part that separates a genuine attack-path assessment from a prettier vulnerability scan. In fifteen years we've never seen a tool replace the tester who looks at four unremarkable findings and sees the one dangerous sequence connecting them.

What this changes about how you buy

Moving from annual VAPT to continuous validation is really a change in what you're purchasing. You stop buying a document and start buying a relationship. You stop asking "how many findings did we get?" and start asking "which of our controls actually stop an attack, and can you prove they still do?"

For UAE organisations there's a compliance dividend too. Frameworks like NESA and ADHICS increasingly expect ongoing assurance rather than an annual artefact, and a continuous programme produces exactly the evidence trail auditors are starting to ask for — not a stale PDF, but a living record of what was found, what was fixed, and what was confirmed closed.

The honest takeaway

We're not going to tell you the annual pentest is dead; for smaller estates with a stable footprint, it's still a reasonable baseline. But if your environment changes constantly — cloud, new identities, frequent deployments, the normal state of any growing business — then testing it once a year is testing it almost never, and hoping the other fifty-one weeks look after themselves.

Where the annual test still earns its place

To be fair to the model we're arguing against: there are situations where an annual test is genuinely enough, and pretending otherwise just sells people programmes they don't need. If your estate is small and stable — a handful of systems that rarely change, no constant stream of deployments, no sprawling cloud footprint — then testing once a year, done properly with real manual depth, is a reasonable baseline. Some compliance obligations are also satisfied by a point-in-time assessment, and there's no sense over-buying to impress a framework that asks for less. The judgement call is about rate of change, not company size. A small fintech shipping code every week has a more volatile attack surface than a large manufacturer whose systems barely move, and it's the volatility that decides whether annual testing is prudent or negligent. Be honest with yourself about which you are. If your environment genuinely holds still, keep the annual test and spend the difference elsewhere. If it changes constantly and you're still testing it once a year, you're not managing exposure — you're sampling it once and hoping the other fifty-one weeks look after themselves.

They don't. The attacker doesn't wait for your budget cycle. Your testing shouldn't either. If you want to talk through what a continuous programme would look like for your estate — and what it would cost relative to the annual ritual — we're happy to scope it with you.