What Changes by Your Third VAPT

Organisations testing for the first time often expect the second and third engagements to look like the first with fewer findings. They tend to look different instead, and knowing the shape in advance makes the results easier to read, and easier to argue for internally.

The first engagement

The first report is normally the longest, and a large share of it is hygiene: missing security headers, outdated components, verbose error messages, default configuration left in place, credentials that were fine in development, permissions granted during a migration and never narrowed.

These are real findings and worth fixing. Most of them are also accumulation: the residue of every decision made under time pressure since the system was built, surfacing at once because nobody had looked before.

The first report often lands badly for that reason. A long list reads as an indictment of the team when it is mostly an artefact of testing for the first time. You are clearing a backlog, once.

The first engagement also spends the most time on discovery, so it usually costs more for the same scope than the ones that follow.

The second

Two things change.

First, the hygiene findings largely do not return, provided they were fixed at the class level and not instance by instance. If the same categories reappear, that is the most useful signal the second test produces: the fixes went to the class level and not to the practice that generated them.

Second, the tester reaches further. Time not spent on discovery and hygiene goes into the parts of the application that take longer to understand: multi-step workflows, role boundaries, the interaction between features. The findings get fewer and more specific.

A much shorter second report is normal. One that finds nothing at all usually means the scope was too narrow or the test was thin.

The third

By the third, the remaining findings share a quality: they required somebody to understand what your system is for.

Business logic that can be driven in an unintended order. A role boundary that holds in nine places and not the tenth. A race condition between two operations that are individually correct. An assumption made in one component that a second component does not honour.

These are the findings automation cannot reach, and they are the reason the engagement is worth buying once the hygiene is gone. They are also fewer, harder-won and often more consequential than anything in the first report.

The relationship changes too. A tester on a third engagement knows the system, so less time goes on re-learning it and the questions get sharper. Ask whether you get the same people; that continuity is a real part of what you are paying for.

Where the arc goes wrong

The quiet report read as an achievement. The most common error at the third engagement. A short report can mean the system genuinely improved, the scope stayed still while the system moved on, or the test was less thorough. All three look identical from the outside, and the way to tell them apart is to ask what was tested this time that had not been tested before.

Scope that never rotates. Testing the same application every year while the estate grows around it produces increasingly reassuring reports about a decreasing share of your exposure.

Vendor familiarity becoming a blind spot. Continuity is valuable, and everyone develops habits about where they look first. After several engagements, bring in a fresh pair of eyes.

Fixing instances, not classes. The failure that shows up as the same categories recurring, engagement after engagement. The consolidation step in prioritising findings for remediation is what prevents it.

What to measure across engagements

Counts of findings are a weak metric, because they move with scope, with tester and with what was in the code that quarter.

More informative: whether previously fixed classes stayed fixed; how long findings took to close by severity band; whether the findings are moving from hygiene toward logic, the direction maturity takes; and how much of the estate has been tested at all.

That last one is usually the least flattering number and the most useful.

How to set the interval in the first place is in how often you should run a VAPT.