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

A vulnerability assessment starts around ¥300,000 when the work is tool-led and around ¥1,000,000 once a security engineer is doing the probing. Yet the same "web application assessment" can come back quoted at ¥300,000 from one provider and ¥3,000,000 from another. Neither quote is wrong. They are counting different things.

What providers publish

Assessment providers publish indicative pricing on their own sites. The table below summarises it.

Table 1: Cost by assessment method (market estimate based on published Japanese pricing)

Running a free scanner yourself sits outside this table; these are the figures for commissioning a provider.

The ranges are wide because providers assume different target sizes. Normalising for size tightens them.

Table 2: Cost by target size

The bottom row is defined by complexity rather than page count, so it overlaps the page-count bands. These are per-assessment figures; run one a year and that is the annual line item.

What produces the spread

Four decisions account for most of the difference between quotes.

What is being assessed

"Vulnerability assessment" covers inspecting how a web application is built, checking OS and middleware configuration against known flaws, testing a mobile app, or reviewing cloud permissions — different work in each case. 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.

How deep the testing goes

This moves the number more than anything else, and depth has several dimensions of its own (next section).

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.

Comparing quotes is much faster once these four are held constant.

What determines depth

Which accounts and roles are provisioned

Covering only what is reachable anonymously, versus being issued test accounts and walking the authenticated screens. Beyond that, the number of roles changes the workload — ordinary user against administrator, or two tenants on separate contracts. Multi-factor authentication and single sign-on add setup effort of their 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? This class needs no specification — two accounts and a comparison will establish it. The cost driver is combinatorial: 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. Sharing the specification and the operational assumptions improves coverage here, and this 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. What tends to be negotiated separately is irreversible action and load testing against availability. Whether the work runs against production or an equivalent environment — and who builds that environment — also moves the number.

How much internal information is shared

Working purely from the outside, or receiving specifications, design documents, API definitions, and source. The more that is shared, the further testing reaches into places black-box probing struggles with: concurrency races and cryptographic misuse are typical examples.

What happens between assessments

An annual assessment confirms the state of a system at the time it ran, which leaves roughly a year unconfirmed.

Three things move during that window. 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 too. 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 third is that 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.

This is not an argument against assessments. Looking deeply requires people. It is an argument that looking deeply and looking often are different jobs, and neither substitutes for the other.

What continuous coverage costs

Continuously discovering and monitoring internet-facing assets is sold as attack surface management (ASM) and priced monthly, which changes how the cost presents.

Among Japanese services that publish a price, self-serve offerings start in the tens of thousands of yen per month, and those bundling analyst-led operation run above ¥100,000. Plenty of services publish no price at all, in which case the figure only arrives after a conversation. PentaTrail is ¥40,000/month for ASM and ¥68,000/month for CTEM.

Table 3: What each spend actually confirms

"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. ASM covers discovery and detection.

The same budgeting question has two answers in different price bands. The bands overlap, so lining up the numbers will not pick a winner. What deserves comparison is not the figure but what the figure confirms.

Continuous monitoring stops at the login wall

Externally observed ASM, PentaTrail included, watches what is reachable without authenticating. Where a login is required, it can tell you the wall is there, but it does not sign in and walk the screens behind it.

PentaTrail works the same way. Paths that require authentication are recorded as requiring authentication, and nothing goes past that point. Confirming whether an attack actually succeeds is also done remotely and non-destructively by design, so routes that would write data are never taken. No specification is handed over either, which puts the "well-formed but forbidden by this business" category above out of scope as well.

The other blind spots are worth stating. Systems reachable only from inside the network, source code and dependency inventories, employee endpoints, identity providers and cloud control planes are not covered by external observation, and stay out of scope unless a separate integration is set up. Discovery also works outward from the domains you register, so a domain with no externally visible relationship to them has to be added by hand.

So continuous monitoring covers the surface an attacker touches first. The number and state of those entry points shift daily, which suits watching them continuously; what sits behind a login changes when the product changes, which suits looking deeply at each release. Both get called "assessment", and they guard different ground.

Sequencing beats choosing

This is not an either-or decision; ordering the two is what matches practice.

When the scope is meant to cover everything the organisation exposes, the inventory of what is externally reachable often does not exist yet, and without a scope there is no quote. Continuous monitoring starts by finding those assets itself, which gives the scoping conversation something to work from.

With an inventory in hand and the important surfaces identified, manual assessment can be aimed at them specifically. Quoted against a defined target rather than an open-ended one, the number becomes predictable — though assets nobody knew about will widen the scope rather than narrow it, so it does not automatically come down.

Check the scope before comparing prices

The spread in quotes is not evidence of a vague market. It exists because what gets examined, and how far, differs by provider. Lining up figures is not a comparison; matching the unit, the depth, and the post-report support is what makes "expensive" and "cheap" mean something.

Settling that scope takes an inventory of what is visible from outside. Quotes produced in the reverse order tend to grow later.

PentaTrail is ¥40,000/month for ASM and ¥68,000/month for CTEM, with the price and the included scope both published before signup. A 14-day trial returns the inventory of what is externally visible for your own domains.

• Pricing
• ASM (Attack Surface Management) — A Beginner's Guide
• What is CTEM? A Complete Guide to the 5 Phases

Cost ranges are compiled from pricing that Japanese vulnerability assessment providers published as of 4 August 2026. Actual quotes vary with scope and method. PentaTrail figures are our own published prices.