A vulnerability assessment service is a scoped, systematic search for security weaknesses across an agreed set of assets, run against a named methodology and reported with severity, business impact and remediation guidance. Buying one well comes down to four decisions: which assets are in scope, how much access the testers get, how far the work goes past automated scanning, and whether the vendor returns to verify your fixes. Two proposals that both say VAPT on the cover page can differ on all four and still land within a few thousand dollars of each other. This guide gives you the brief, the questions and the specific red flags that separate them.
The stakes moved in 2026. According to Verizon's 2026 Data Breach Investigations Report, 31% of breaches now start with software vulnerabilities, beating stolen passwords for the first time in the report's 19-year history. The same report puts the median time to fully remediate a vulnerability at 43 days, which is worse than the 32 days it recorded the year before. Attackers got faster at using flaws while defenders got slower at closing them, and that gap is what you are actually buying an assessment to shrink.
Where this sits: this is a standalone buyer's guide inside Vervali's security testing cluster. It sits alongside the service pages for vulnerability assessment services, penetration testing services, the combined VAPT testing services page and the wider security testing practice. It assumes you already know how a vulnerability assessment differs from a penetration test, and it spends its time on the buying decision instead.
What You'll Learn
The four scope dimensions that decide what a vulnerability assessment actually costs and covers
How to write one brief that makes three vendor quotes comparable line for line
Which named standards are still maintained in 2026, and which carry a much older date than vendors imply
The red flags specific to vulnerability-assessment-only engagements, which most vendor checklists skip
What regulation requires by name and by date under PCI DSS 4.0.1, DORA, NIS2 and CISA BOD 26-04
| Metric | Value | Source |
|---|---|---|
| Breaches starting with software vulnerability exploitation | 31% | Verizon 2026 DBIR |
| Median time to fully remediate a vulnerability | 43 days, up from 32 | Verizon 2026 DBIR via Help Net Security |
| Median days from CVE publication to known-exploited listing | 80 in 1H-2026, down from 120 in 2025 | VulnCheck |
| Known-exploited flaws attacked on or before CVE publication | 23.43% | VulnCheck |
| PCI DSS internal and external vulnerability scan cadence | At least every 3 months | PCI DSS v4.0.1 |
| DORA threat-led penetration testing cadence | At least every 3 years | DORA Article 26 |
Why Do Two VAPT Proposals at the Same Price Cover Different Work?
Because the label is not the specification. VAPT, vulnerability assessment, security audit and security assessment are all sold across a wide range of scopes, and the word on the proposal cover tells you almost nothing about the depth underneath it. One vendor can price a quarterly authenticated scan of forty external hosts. Another can price manual testing of one web application with business-logic abuse cases and a retest. Both quotes can read as VAPT and land at similar numbers, and only one of them addresses the risk that keeps your CTO awake.
Vervali's own vulnerability testing page frames the service as three connected components: vulnerability scanning with risk assessment, continuous vulnerability monitoring, and penetration testing. That is a defensible bundle, and it is also proof of the point. Anyone reading "vulnerability assessment services" on a vendor site is looking at a container whose contents vary, and the only way to compare containers is to specify the contents yourself before anyone quotes.
Scope breadth is measurable. One end-to-end engagement Vervali delivered for a SaaS gaming platform covered web applications, mobile applications, APIs, source code and backend infrastructure in a single programme, black-box and grey-box, with threat modelling and attack-path analysis, and closed with remediation recommendations and revalidation. The outcome recorded was 100% coverage across agreed web, mobile, API, source-code and infrastructure scope, with critical vulnerabilities found before production deployment. Set that beside a proposal that names one asset class and no retest, and the price similarity stops being confusing.
Key Finding: "31% of breaches now start with software vulnerabilities, beating stolen passwords." Verizon, 2026 Data Breach Investigations Report, covering incidents between 1 November 2024 and 31 October 2025.
Which Four Scope Dimensions Should Your Brief Define?
Every vulnerability assessment resolves into four dimensions, and a brief that fixes all four turns a set of incomparable quotes into a like-for-like comparison. Leave any one of them open and vendors will each fill it differently, then price their own version.
Asset categories. List the systems by class and by count: external web applications, internal web applications, public APIs, mobile applications by platform, source-code repositories, servers, network segments, wireless networks, cloud accounts. Counts matter more than categories, because effort scales with instances. Vervali's cluster splits along these same lines, with dedicated pages for application security testing, infrastructure security testing, network security testing and mobile app security testing. If a single line item on a quote silently spans three of those, ask for it to be broken out.
Access level. NIST Special Publication 800-115 sets the vocabulary the industry still uses: white box means source-code access, black box is performed against the application binary without source-code knowledge, and testing that combines both is gray box. Authenticated testing finds a different class of defect from unauthenticated testing, so state whether credentials, test accounts and roles will be provided, and how many roles.
Depth. This is the dimension vendors compress hardest. Automated scanning, manual verification of scanner output, manual testing beyond scanner coverage, business-logic testing, threat modelling and attack-path analysis are five different levels of effort. NIST warns that vulnerability scanners can carry a high false-positive rate and may rate each finding low individually while leaving the assessor falsely confident, because the scanner never chains findings together the way an attacker does.
Revalidation. Decide up front whether the engagement ends at the report or ends when fixes are confirmed. PCI DSS v4.0.1 settles this for anyone in payments: Requirement 11.4.4 obliges organisations to correct exploitable vulnerabilities found in a penetration test and to repeat the testing to verify the corrections.
| Scope dimension | Specify in the brief | What a vague version looks like |
|---|---|---|
| Asset categories | Named systems with counts per class | "Your web estate" |
| Access level | Black box, gray box or white box, plus role count | "As agreed during kickoff" |
| Depth | Scan, manual verification, manual testing, business logic, threat modelling | "Industry standard testing" |
| Revalidation | Retest window, retest scope, who pays | "Retest available on request" |
For a worked example of how far one category opens up under scrutiny, our analysis of mobile app security testing takes a single asset class down to threat level and the cost of missing it.
How Do You Get Three Vendors to Quote the Same Thing?
Write the scope brief yourself and send the identical document to every vendor. NIST SP 800-115 has carried the template for this since 2008 in its Rules of Engagement appendix, and two of its requirements are the ones buyers most often leave out. The first is a Target System or Network section that names every authorised system. The second is the exclude list, which NIST describes as identifying any system not authorised for testing. A brief with an exclude list produces quotes you can compare; a brief without one produces a scoping call per vendor and three different answers.
Then score the responses on more than price. Weighted rubrics used across security procurement spread the decision across understanding of requirements, experience, methodology, deliverables and reporting, timeline and cost, with cost carrying roughly a fifth of the total. The weights matter less than writing them down before the proposals land, because a rubric agreed after you have read the quotes is a rationalisation.
Watch the line items that appear on one quote and not another. Threat modelling, source-code review, retesting, an executive readout and remediation support are the five that most often explain a price gap, and a cheaper proposal is sometimes cheaper because it excludes three of them.
| Comparison line | Vendor A | Vendor B | Question if they differ |
|---|---|---|---|
| Assets and counts | Stated per class | Bundled as one line | "Which specific systems does this cover?" |
| Access level | Gray box, 3 roles | Unspecified | "Are you testing authenticated paths?" |
| Manual effort | Named days | Not stated | "How many days are hands-on-keyboard?" |
| Threat modelling | Included | Absent | "Is attack-path analysis in scope?" |
| Retest | Included, 60 days | Quoted separately | "What does the retest cost and cover?" |
| Report sample | Redacted sample supplied | Refused | "Can we see a redacted report first?" |
Pro Tip: Ask for the phrase "agreed in-scope" to appear in the statement of work next to every coverage claim, along with the exclude list it refers to. A vendor claiming 100% coverage of agreed in-scope assets is describing the boundary you both signed. A vendor claiming 100% coverage with no boundary named is describing something that cannot be delivered.
What Should You Ask About Methodology and Named Standards?
Ask which named standard governs each asset class, and which edition. This is a sharper question than it sounds in 2026, because the documents vendors cite are maintained on very different schedules and a buyer who does not check will assume they are all current.
OWASP's Web Security Testing Guide is the most cited web-application testing methodology in the industry, and its current stable release is version 4.2, dated 3 December 2020. OWASP's own project page states that version 5.0 is still in development with no ship date. It is still the right reference to name, and it has been stable for over five years, which is worth knowing before you treat "OWASP-aligned" as a freshness signal.
Mobile is the opposite case. OWASP's Mobile Application Security Verification Standard reached v2.1.0 on 18 January 2024, and its companion testing guide, MASTG, reached v2.0.0 on 30 June 2026. If a vendor's mobile scope language still references MASVS verification levels L1 and L2, the reference predates the v2 refactor and the methodology behind the quote is older than the quote is.
PTES, the Penetration Testing Execution Standard, is still published in full with all seven of its phases, and it carries a 2012 publication date. Its site is served over plain HTTP; the HTTPS endpoint does not respond at all, and the ptes.org domain belongs to an unrelated wildlife charity. None of that makes the standard wrong. It does mean that a proposal naming only PTES is leaning on a weaker credibility signal than one naming NIST SP 800-115 or the current OWASP guides, which are actively maintained and served over TLS.
| Standard | Covers | Current edition | Ask the vendor |
|---|---|---|---|
| NIST SP 800-115 | Technique taxonomy, rules of engagement, reporting | Final, 30 September 2008 | "Does your ROE follow the Appendix B structure?" |
| OWASP WSTG | Web application testing procedures | v4.2, 3 December 2020 | "Which WSTG test IDs are in scope?" |
| OWASP MASVS | Mobile security requirements | v2.1.0, 18 January 2024 | "Are you on the post-2023 v2 control set?" |
| OWASP MASTG | Mobile testing procedures | v2.0.0, 30 June 2026 | "Which MASTG tests will you run?" |
| CVSS | Severity scoring | v4.0, specification published 1 November 2023 | "Which CVSS version scores our findings?" |
How Should a Vendor Prioritise Findings Beyond a CVSS Score?
A severity score answers one question, which is how bad the outcome would be if the flaw were exploited. It does not answer whether anyone is likely to exploit it in your environment this quarter. The vendors worth hiring can explain how they handle the second question, and the standards bodies have already moved in that direction.
CVSS v4.0, maintained by FIRST, defines five severity bands: None at 0.0, Low from 0.1 to 3.9, Medium from 4.0 to 6.9, High from 7.0 to 8.9 and Critical from 9.0 to 10.0. FIRST separately publishes EPSS, which it describes as a data-driven machine-learning model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days. Severity and exploit likelihood are different measurements, and a report that carries only the first is handing you a queue with no ordering logic.
Regulators are making the same move. CISA issued Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk", on 10 June 2026, replacing a flat known-exploited-vulnerability mandate with a framework built on four variables: public exposure, known-exploited status, how automatable the exploit is, and technical impact. FedRAMP's notice on the directive records the federal deadlines that follow, with agency policies due to support ongoing remediation by 7 August 2026 and remediation to the new timelines beginning by 7 December 2026. Those dates bind US federal civilian agencies rather than private buyers, and the direction of travel is the part that generalises.
The timing data explains why. Per VulnCheck's own research across the 495 known-exploited vulnerabilities it added in the first half of 2026, the median time from CVE publication to known-exploited listing fell from 120 days in 2025 to 80 days in 1H-2026, and 23.43% of those flaws showed evidence of exploitation on or before the day the CVE was published. For roughly a quarter of them there was no patch window at all.
Watch Out: PCI DSS Requirement 11.3.2.1 obliges you to resolve any vulnerability "scored 4.0 or higher by the CVSS" after a significant change. That 4.0 is a numeric score sitting at the Low and Medium boundary, and it applies under any CVSS version. It is not a reference to CVSS version 4.0, despite the coincidence in the numbers. If a vendor reads it the second way, their remediation trigger is wrong.
What Are the Red Flags in a Vulnerability Assessment Proposal?
Most published red-flag lists are written about penetration tests. Vulnerability-assessment-only engagements have their own failure modes, and because a VA is expected to lean on automated tooling, the usual advice about demanding manual exploitation does not transfer cleanly. These are the six that matter.
An automated scan sold as an assessment. A scan is an input to an assessment, and on its own it is not one. NIST SP 800-115 draws the line precisely: vulnerability scanners check only for the possible existence of a vulnerability, while the attack phase of a penetration test exploits the vulnerability to confirm its existence. PCI DSS v4.0.1 states the same thing in its own guidance, that scanning for vulnerabilities alone is not a penetration test. The tell in a proposal is the absence of any named human effort. Ask how many days are hands-on and who validates scanner output before it reaches your report.
Severity ratings with no named scoring system. If findings arrive as High, Medium and Low with no CVSS version, no vector string and no stated methodology, the ratings are a vendor opinion formatted as data. You cannot reconcile them against a previous assessment, against your own risk register, or against a second vendor's findings. Ask for the CVSS version and the full vector string on every finding.
No revalidation in the scope. An assessment that ends at the report leaves you with a list and no evidence that the list got shorter. NIST is explicit that verifying a fix requires a mirror copy of the original test to be performed, so a retest that samples a few items is a different product from one that repeats the assessment. Ask what the retest covers, how long the window is, and whether it is included.
No named methodology, or a methodology with no edition. "OWASP-aligned" is not a methodology statement until it names which OWASP document and which version. The same applies to "industry standard", "best practice" and "NIST-based". Ask for document names and version numbers in the statement of work.
No rules of engagement. A scoping conversation that stays on price and timeline, with no written definition of testing boundaries, authorised systems, an exclude list, testing windows, escalation contacts and what happens if the testing takes a system down, is not a scoping conversation. NIST treats the exclude list as a baseline requirement rather than an optional nicety.
A turnaround that does not fit the scope. Effort is bounded by asset count and depth, so a quote promising a full assessment of a large estate inside a few days is describing a scan schedule, and the honest version of that quote says so. Ask for the number of testing days behind the calendar date.
Watch Out: Severity inflation is the quietest of these. A report where a large share of findings arrive as Critical or High, with no exploit-likelihood context and no business impact narrative, generates work rather than reducing risk. It also looks impressive in a debrief, which is why it survives. Check the distribution of severities in the redacted sample report before you sign, and ask how many of the Highs the vendor confirmed by hand.
What Does Regulation Actually Require, and By When?
Cadence advice is more useful when it is attached to a clause and a date. Four regimes carry dated obligations that a buyer in a regulated sector should hold their vendor to.
PCI DSS v4.0.1, published June 2024 by the PCI Security Standards Council, splits scanning and penetration testing into two separate controls. Internal and external vulnerability scans are required at least once every three months under Requirements 11.3.1 and 11.3.2, with external scans performed by a PCI SSC Approved Scanning Vendor. Internal and external penetration testing are required at least once every 12 months and after any significant infrastructure or application change, under 11.4.2 and 11.4.3. Several sub-requirements carried a best-practice grace period until 31 March 2025, which means they have been mandatory for over a year at the time of writing.
DORA, Regulation (EU) 2022/2554, applies from 17 January 2025 with no grace period. Per Article 26, in-scope financial entities other than microenterprises must carry out advanced testing by means of threat-led penetration testing at least every three years, and a competent authority can shorten that based on risk profile. TLPT is a heavier engagement than a standard vulnerability assessment, so if you are in scope, price it separately.
NIS2, Directive (EU) 2022/2555, required Member State transposition by 17 October 2024, with provisions applying from 18 October 2024. Transposition remains uneven: the European Commission opened infringement procedures against 23 Member States on 28 November 2024 for missing the deadline, so the operative obligation for a given entity is the national implementing law rather than the directive text.
ISO/IEC 27001:2022 Annex A control 8.8 is a three-step control covering technical vulnerabilities: obtain information about them, evaluate the organisation's exposure, and take appropriate measures. It does not name scanning or penetration testing, and it sets no cadence. A vendor who tells you ISO 27001 certification requires quarterly pentests has misread it.
| Regime | Obligation | Cadence | Date in force |
|---|---|---|---|
| PCI DSS v4.0.1 | Internal and external vulnerability scans | Every 3 months | Current version June 2024 |
| PCI DSS v4.0.1 | Internal and external penetration testing | Every 12 months plus after significant change | Grace period ended 31 March 2025 |
| DORA Article 26 | Threat-led penetration testing | At least every 3 years | Applies from 17 January 2025 |
| NIS2 | Risk-management measures via national law | Set by Member State | Transposition due 17 October 2024 |
| CISA BOD 26-04 | Risk-tiered remediation, US federal civilian agencies | Per directive timelines | Issued 10 June 2026 |
Which Certifications and Schemes Actually Mean Something?
Certifications answer narrower questions than vendors imply, and knowing which question each one answers is most of the work. ISO/IEC 27001 certifies an information security management system, so it tells you how a vendor protects information, including yours. ISO 9001 certifies a quality management system, so it speaks to process consistency. ISO/IEC 17025:2017 is different in kind: it accredits the competence, impartiality and consistent operation of a testing laboratory, which is a statement about the technical soundness of the testing itself. It is rare among software testing firms. CMMI Maturity Level 3 speaks to process maturity and reads well to enterprise and government procurement.
Scheme memberships answer a different question again. CREST accredits at company level through audit and at individual level through enforceable codes of conduct, and describes its member audits as meaningful market differentiators. The UK NCSC's CHECK scheme is narrower still: it covers companies assured to conduct authorised penetration tests of public sector and critical national infrastructure systems, which makes it decisive for a UK government engagement and largely irrelevant to a commercial SaaS buyer. Ask what a named scheme actually covers before treating it as a differentiator.
Then ask about people, separately from the company. Company accreditation and individual qualification are different claims, and a vendor should be able to name the individuals who will run your engagement and say what each of them holds. Vervali holds four organisational credentials: ISO/IEC 17025:2017, CMMI Maturity Level 3, ISO 9001:2015 and ISO/IEC 27001. It does not publish individual practitioner certifications, and a buyer running this checklist should ask any vendor, including this one, to name the team on the engagement and put those names in the statement of work.
What Proof Should a Vendor Show Before You Sign?
Ask for two artefacts: a redacted sample report from an engagement resembling yours, and a case description carrying scope, method, tooling and a measurable outcome. Marketing claims collapse quickly under both.
A credible sample report carries reproduction steps, evidence, the CVSS version and vector for each finding, business impact written in the client's terms, and remediation guidance specific enough to hand to an engineer. Vervali's penetration testing page describes its own deliverable in those terms: a detailed report identifying vulnerabilities and the methods used to exploit them with severity ratings, plus risk analysis, remediation guidance and an executive summary. Hold every vendor to that shape, including this one.
Credible case descriptions carry numbers that a marketing team could not have guessed. One vulnerability-management engagement Vervali delivered for a leading private-sector bank, which stays anonymous at the client's request, centralised risk-based vulnerability management across prioritisation, remediation workflows, SLA tracking, approvals and reporting. The recorded outcomes were a 68% reduction in vulnerability noise, a 30% improvement in remediation time, mean time to remediate improving from 40 or more days to under 16 days, an 80% reduction in audit-preparation effort from roughly five days to five hours, and a 3.5x improvement in the high-risk vulnerability closure rate.
Read the coverage claims closely. Across five releasable security engagements, Vervali's stated outcomes are 100% coverage of agreed in-scope servers and network components for a digital recharge and payment platform, 100% coverage of agreed in-scope web applications and infrastructure for a global marine technology organisation, and 100% coverage of agreed critical API workflows across authentication, transactions and data exchange for a UAE SME finance-management platform. Those two words, "agreed in-scope", carry the meaning. They describe the boundary both parties signed, and they say nothing about assets outside it. A coverage claim without them is describing a completeness no assessment can deliver.
Pro Tip: Ask for one reference customer in your sector whose engagement had a retest. Reference calls about the initial report tell you how a vendor sells. Reference calls about the retest tell you how a vendor finishes.
How Does Vervali Approach Vulnerability Assessment Work?
Vervali runs security work as a six-stage lifecycle rather than a single deliverable: threat modelling and risk assessment to identify attack surfaces and high-risk exposure points, test planning to fix scope and compliance objectives, environment setup in controlled test labs, vulnerability assessment and penetration testing combining automated and manual work, reporting with severity scoring and remediation guidance, and continuous monitoring with retesting to validate patches. A methodology reused across engagements keeps the scoping conversation on your risk instead of the vendor's process.
The five releasable engagements span infrastructure, web, API, mobile and source-code scope across payments, marine technology, fintech, banking and SaaS gaming, black-box and grey-box, with threat modelling, attack-path analysis, controlled exploitation and revalidation. Tooling is consistent and named: Burp Suite appears in all five, alongside OWASP ZAP, Metasploit, Tenable, OpenVAS, Wireshark, Postman with Swagger and OpenAPI for API work, and MobSF with Frida on mobile. For a closer look at the open-source end of that toolchain, see our guide to MobSF and the MASTG toolchain.
The credential worth checking is ISO/IEC 17025:2017. A testing-laboratory competence accreditation speaks directly to the technical soundness of a testing methodology, and it is uncommon among software quality assurance firms. Alongside CMMI Maturity Level 3, ISO 9001:2015 and ISO/IEC 27001, it describes an organisation audited on how it tests, which is the question a vulnerability assessment buyer is actually asking.
TL;DR: Vulnerability assessment services are sold under labels that hide four decisions: asset scope, access level, testing depth and revalidation. Write one brief that fixes all four, include an exclude list, and send the same document to every vendor. Score methodology, deliverables and retest alongside price. Require a named standard with a version number, a named CVSS version on every finding, and the words "agreed in-scope" next to any coverage claim. Verizon's 2026 DBIR puts 31% of breaches on exploited software flaws while median remediation slipped to 43 days, so the engagement that closes findings beats the one that only lists them.
Ready to Scope a Vulnerability Assessment Properly?
Vervali delivers vulnerability assessment and penetration testing across web, mobile, API, source-code and infrastructure scope, with threat modelling, controlled exploitation, remediation guidance and revalidation, backed by ISO/IEC 17025:2017 and CMMI Maturity Level 3. Explore VAPT testing services or bring your scope brief to a conversation about what it should contain.
Sources
Verizon Business (2026). "2026 Data Breach Investigations Report." https://www.verizon.com/business/resources/reports/dbir/
Help Net Security (2026). "Verizon 2026 DBIR findings." https://www.helpnetsecurity.com/2026/05/20/verizon-2026-dbir-findings/
VulnCheck (2026). "State of Exploitation, 1H-2026." https://www.vulncheck.com/blog/state-of-exploitation-1h-2026
Scarfone, K., Souppaya, M., Cody, A., Orebaugh, A. (2008). "NIST Special Publication 800-115: Technical Guide to Information Security Testing and Assessment." https://nvlpubs.nist.gov/nistpubs/legacy/SP/nistspecialpublication800-115.pdf
PCI Security Standards Council (2024). "PCI DSS Requirements and Testing Procedures, v4.0.1." https://www.pcisecuritystandards.org/document_library/
OWASP Foundation (2020). "Web Security Testing Guide v4.2." https://owasp.org/www-project-web-security-testing-guide/
OWASP Foundation (2024). "MASVS v2.1.0 release." https://github.com/OWASP/masvs/releases/tag/v2.1.0
OWASP Foundation (2026). "MASTG v2.0.0 release." https://github.com/OWASP/mastg/releases/tag/v2.0.0
FIRST.org (2023). "CVSS v4.0 Specification Document." https://www.first.org/cvss/v4.0/specification-document
FIRST.org. "EPSS: Exploit Prediction Scoring System." https://www.first.org/epss/
CISA (2026). "Binding Operational Directive 26-04: Prioritizing Security Updates Based on Risk." https://www.cisa.gov/news-events/directives
FedRAMP (2026). "Notice on CISA BOD 26-04." https://www.fedramp.gov/notices/0014/
European Union (2022). "Regulation (EU) 2022/2554 (DORA), Article 26." https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng
European Union (2022). "Directive (EU) 2022/2555 (NIS2)." https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022L2555
ISO/IEC (2017). "ISO/IEC 17025:2017 General requirements for the competence of testing and calibration laboratories." https://www.iso.org/standard/66912.html
CREST. "About CREST accreditation." https://www.crest-approved.org/
UK National Cyber Security Centre. "CHECK penetration testing scheme." https://www.ncsc.gov.uk/schemes/check/introduction
ISMS.online (2022). "ISO/IEC 27001:2022 Annex A Control 8.8." https://www.isms.online/iso-27001/annex-a-2022/8-8-management-of-technical-vulnerabilities-2022/
Email Us
Call Us
