Skip to main content

How a VAPT Scope Gets Sized

Testers do not count lines of code. They count functions, roles and entry points. What actually drives the number of days, and how to give a vendor enough to quote accurately.

3 min read

Ask three vendors to quote the same system and the estimates can differ by a factor of two. That is usually not because one is overcharging. It is because they were given different information and made different assumptions about what was in scope.

Understanding what a tester actually counts makes those quotes comparable.

What is not the measure

Lines of code. A hundred thousand lines implementing four screens is a small test. Ten thousand implementing a permission system with six roles is not.

Number of servers. Forty identical web servers behind a load balancer are approximately one target.

Number of microservices. If thirty services sit behind one gateway and expose twelve endpoints between them, the attack surface is twelve endpoints.

What all three have in common is that they measure how much was built. Testing time follows how much can be reached.

What a tester counts

Web applications

Distinct functions, not pages — a list view and its detail view are one function; a search, an export and a bulk edit are three. Then the number of roles, because each one multiplies the authorisation testing. Then the authentication surface: login, registration, password reset, multi-factor, single sign-on, session handling. Administrative interfaces count separately, because they are usually a different application wearing the same brand.

APIs

Endpoints and the methods on them. Distinct authentication schemes. Whether the specification is trustworthy — if it is out of date, the tester has to establish reality first, and that is discovery time. For GraphQL, the number of types and resolvers rather than the single HTTP endpoint.

Mobile

Platforms multiply. Android and iOS sharing one backend is three targets: two binaries with platform-specific issues, plus the API tested once. A quote that treats two platforms as one has either scoped one of them thinly or intends to skim.

Networks

Live hosts with services listening, not address space. A /16 that is 3% populated is smaller than a fully occupied /24. Because that is unknown before discovery, network quotes often have a discovery phase priced separately, which is honest rather than evasive.

What legitimately inflates a scope

  • More roles. Necessary cost — authorisation testing is where the serious findings are, and it needs the accounts.
  • Bespoke authentication or signing. A custom scheme costs a day or more before testing starts.
  • Complex multi-step workflows. Where the business logic flaws live.
  • Genuinely different components. A React front end, a legacy admin panel and a mobile app are three exercises.

What inflates it unnecessarily

  • Multiple environments. Testing staging and production when they are the same build is buying the same test twice.
  • Repeated identical instances. Forty deployments of one product is one test plus a configuration comparison.
  • Scoping by asset register. Registers include things that were decommissioned, and exclude things nobody wrote down. The external discovery phase is the corrective.

How to brief for an accurate quote

Six items, and they take under an hour to assemble:

  • What the system does, in two sentences.
  • The roles, and what distinguishes them.
  • A rough count of distinct functions — an estimate is fine.
  • The technology, and anything unusual about authentication.
  • Whether an API is in scope as a target in its own right, or only as the thing the front end talks to. This single question accounts for more quote variance than any other.
  • Any hard constraints — change freezes, environments, third-party components you cannot authorise.

Give all vendors the same brief. Otherwise you are comparing quotes for different pieces of work and choosing the one that assumed least.

Reading the quotes

Convert everything to tester-days. That is the unit vendors actually price in, and it makes proposals comparable when their packaging is not.

Then check three things: whether reporting time is included in the day count or added, whether retesting is included, and what the daily rate implies about who is doing the work. A quote that is half the others is not a discount on the same thing — it is fewer days, or less experienced people, or a scope that quietly dropped the API.

A fixed price offered before anyone has seen the system is a price, not an estimate. It may still be a fair one, but it was set by guessing at the scope, and the risk of that guess is priced in somewhere.

What those days cost and why is in what moves the price of a penetration test. What falls outside the boundary regardless of budget is in what can and cannot be tested.