What a Vulnerability Assessment Costs, and Where the Range Comes From

What is being assessed. Inspecting how a web application is built, checking OS and middleware configuration against known flaws, testing a mobile app, or reviewing cloud permissions are different work. The ranges above are for web application assessments; change the layer and a different quote applies.

The unit being counted. Screens, requests, or FQDNs — the same system yields a different multiplier depending on which one the provider uses. For a service with a large authenticated area, this variable alone can roughly double a quote.

What comes after the report. A report alone, a window for follow-up questions, or a re-test after remediation are priced differently. Handing over raw tool output versus having a person strip false positives and attach reproduction steps also changes the labour, and a re-test billed separately means budgeting twice before anyone can confirm the fix worked.

Which accounts and roles are provisioned. Ordinary user against administrator, or two tenants on separate contracts — the number of roles changes the workload, and multi-factor authentication or single sign-on adds setup effort of its own.

Whether privilege boundaries are probed. Can one user's identifier be swapped for another's and return their data? Can an ordinary account reach administrative functions? Two accounts and a comparison will establish it, but every additional role multiplies the pairs worth testing.

Whether rules specific to the business are in scope. An order accepted after a price or quantity was edited; a confirmation reached with a step skipped. Each is a well-formed request, and only that business's rules make it a defect, which is one of the reasons manual testing costs what it does.

Whether multi-step flows are followed. Cart to payment to confirmation carries state across many requests, and probing endpoints one at a time never walks that path.

Which operations are permitted. Creating and modifying test records is routine in an authenticated assessment, while irreversible action and load testing tend to be negotiated separately, and whether the work runs against production or an equivalent environment moves the number again.

How much internal information is shared. Specifications, design documents, API definitions, and source push testing further into places black-box probing struggles with: concurrency races and cryptographic misuse are typical examples.

Assets accumulate. Subdomains stood up by individual teams, a staging server left reachable, domains inherited through an acquisition. None of them existed at the last assessment, so none appear in the report.

Vulnerabilities accumulate. Without a single line of code changing, a newly disclosed flaw in a shipped dependency turns a server nobody had flagged yesterday into a known target today. A configuration that passed cleanly in January can be exploitable by April.

The system itself changes. Features added, settings altered, permissions reworked, external services connected. Only part of that is visible from outside, and how the privilege boundaries or business rules were reshaped cannot be judged externally at all.

"Candidates" is deliberate: detection and validation are separate steps. Confirming that an attack actually succeeds is a CTEM capability at PentaTrail, applied only to findings that qualify.

Externally observed monitoring watches what is reachable without authenticating. Paths that require a login are recorded as requiring one, and nothing goes past that point. Systems reachable only from inside the network, source and dependency inventories, employee endpoints, identity providers and cloud control planes stay out of scope unless a separate integration is set up. Where the line falls is drawn out in ASM, vulnerability assessment, and penetration testing.