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 usually look like something 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. They are also, mostly, 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 is often received badly for this reason. A long list reads as an indictment of the team when it is mostly an artefact of it being the first time. The useful framing is that you are clearing a backlog, once.

The first engagement also spends the most time on discovery, which is why it tends to cost more for the same scope than the ones after it.

The second

Two things change.

The hygiene findings largely do not return — if they were fixed at the class level rather than instance by instance. If the same categories reappear, that is the most useful signal the second test produces, and it is not really about security: it says the fixes were applied to the instances the report listed rather than 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 second report that is much shorter is normal. A second report finding nothing at all usually means the scope was too narrow or the test was thin, rather than that the system is finished.

The third

By here the remaining findings tend to 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 at all, and they are the reason the engagement is worth buying once the hygiene is gone. They are also fewer, harder-won, and frequently more consequential than anything in the first report.

The relationship changes too. A tester on a third engagement knows the system, which means less time re-learning it and sharper questions — and it is worth asking whether you get the same people, because 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 means one of several things: the system genuinely improved, the scope was unchanged while the system moved on, or the test was less thorough. These look identical from the outside, and the way to tell them apart is to ask what was tested 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 after several engagements a fresh perspective is worth buying occasionally — not because the incumbent is doing badly, but because everyone develops habits about where they look first.

Fixing instances rather than 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, which is the direction that indicates maturity; 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.