VAPT and security testing cost estimator

What you are actually paying for

Security testing is quoted in days, and the only number worth comparing between proposals is how many of those days are manual and who performs them. Automated scanning is cheap, useful and should be running continuously; it is not what a penetration test is for.

Effort scales with attack surface rather than with codebase size. An application with three roles, forty endpoints and one integration is a fraction of the work of one with twelve roles, four hundred endpoints and six integrations, even if the second has less code.

Authenticated testing costs more than unauthenticated and is worth substantially more. Most serious findings, particularly authorisation flaws and business logic abuse, are only reachable with a valid session. A quote that omits authenticated testing is cheaper for a reason.

Retesting should be included. If a proposal prices it separately, add it to the comparison, because a report describing a vulnerability that is still present is not a finished piece of work.

What makes a test more expensive, and when it is worth it

Role count. Every additional privilege level multiplies the authorisation matrix that has to be walked by hand, and this is precisely where the findings that matter live. It is worth the money.

Integrations and third party interfaces, each of which is a trust boundary drawn quickly under delivery pressure. Worth including, because they are frequently the weakest part of an otherwise sound application.

Mobile alongside web. Worth it if a meaningful share of your users are on the app, because the real attack surface is the client most people hold.

Source code access, which raises the day rate slightly and typically pays for itself in depth. A grey box test finds classes of issue a black box test reaches only by luck.

Out of hours testing windows, which cost more and are sometimes unavoidable on production systems. Where a staging environment genuinely mirrors production, testing there is cheaper and safer.

Where cheap testing costs more later

The commonest false economy is a scan sold as a test. It produces a document, satisfies a procurement requirement, and leaves the authorisation and business logic surface entirely untouched. Organisations discover this when a real incident traces to something no scan could have found.

The second is a test with no retest, which leaves you unable to demonstrate closure and, more practically, unable to know whether a fix worked.

The third is a report you cannot act on. If findings arrive without reproduction steps, your developers will spend longer reconstructing them than the discount saved, and some will be dismissed as false positives when they are not.

How to use this number

Treat the output as a planning range for a scope of this shape, not a quote. Two things move it materially once someone looks at your actual estate: the true role count, which is nearly always higher than the initial answer, and how much of the surface is genuinely in scope.

Use it to interrogate proposals rather than to select one. If a quote is well below the range, ask how many manual days it contains. If it is well above, ask what is being tested that you did not think was in scope.

And decide the testing cadence before the first engagement. An annual test on a fortnightly release cycle tells you about an application that no longer exists; the sensible pattern is a full assessment annually with focused testing on significant changes.