Pentest vs Vulnerability Scan: the real difference and which to buy for your company

What a vulnerability scan is and how it works

A vulnerability scan is the process of automated sweeping of digital assets — servers, web applications, APIs, network devices — in search of misconfigurations, outdated software versions, and flaws cataloged in databases such as the NVD (National Vulnerability Database) and CVE. Tools like Nessus, Qualys, OpenVAS, and Tenable.io run this sweep in minutes or hours, cross-referencing the environment's characteristics against signatures of known vulnerabilities.

The result is a list prioritized by CVSS severity — Critical, High, Medium, Low — indicating which systems are most likely to be compromised. That list, however, does not confirm that the flaw is actually exploitable in that specific context. A critical CVE may exist on a port that is inaccessible externally; the scanner doesn't know that. That's why false-positive rates of 20% to 40% are common, depending on the tool and the environment's configuration.

The main advantage of the scan is frequency: it can run daily or in near real time, ensuring continuous visibility of the attack surface. For companies with dozens or hundreds of assets, that continuous coverage is irreplaceable — no team of pentesters can keep that pace manually. The cost is also proportionally low: SaaS solutions start around R$ 500/month for small scopes and reach R$ 8,000/month for large asset estates with management reports included.

What a pentest is and why it's different

A penetration test — or pentest — is a security assessment conducted by specialized professionals who simulate, in a controlled and authorized manner, the behavior of a real attacker. The goal is not to list potential vulnerabilities, but to prove which of them are actually exploitable in the analyzed environment and what the concrete impact would be: access to customer data, lateral movement between systems, compromise of critical infrastructure.

Unlike the scanner, the pentester chains vulnerabilities together. A low-severity flaw in an auxiliary service can be combined with a permission misconfiguration to escalate privileges and reach the main database — a path no automated tool would trace on its own. That capacity for contextual reasoning is what makes the pentest irreplaceable for real risk assessments.

There are different types of pentest depending on scope and the level of initial knowledge: black-box (external attacker with no prior information), gray-box (limited credentials or partial documentation), and white-box (full access to source code and architecture). Each mode answers a different business question. The cost of an external web-application pentest starts around R$ 12,000 for simple scopes and can exceed R$ 80,000 in complex corporate environments with multiple integrated systems.

The pentest report delivers something the scanner never delivers: a reproducible attack narrative, with evidence (screenshots, data dumps, logs), proof of impact, and recommendations prioritized by real risk — not by theoretical CVSS. That document is what security auditors, boards of directors, and cyber-risk insurers need to see.

Comparison table: pentest vs vulnerability scan

The table below consolidates the operational differences between the two approaches. Use it to align expectations with stakeholders and to justify budgets internally: | Criterion | Vulnerability Scan | Pentest | |---|---|---| | **Execution** | Automated (tool) | Manual (specialized professional) | | **Depth** | Surface-level — compares versions and signatures | Deep — chains flaws, exploits context | | **Frequency** | Continuous or daily | One-off (annual, semiannual, or post-change) | | **Average cost** | R$ 500–R$ 8,000/month | R$ 12,000–R$ 80,000+ per cycle | | **False positives** | High (20–40%) | Low — everything reported was confirmed | | **Proof of impact** | No — indicates potential risk | Yes — demonstrates real exploitation and consequence | | **PCI DSS compliance** | Quarterly ASV scan (Req. 11.3.2) | Mandatory annual pentest (Req. 11.4) | | **Main deliverable** | List of CVEs by CVSS severity | Narrative report with evidence and attack chain | | **Execution time** | Minutes to hours | Days to weeks |

No row in the table makes one approach superior to the other — they answer different questions. The scan answers: which assets are exposed right now? The pentest answers: what can a real attacker do with that?

When to hire each (and when to hire both)

Hiring a vulnerability scan makes sense as a continuous practice, regardless of company size. If you operate any digital asset — server, web application, API, VPN — you need to know, in near real time, whether a new critical flaw has been published that affects your environment. Events like Log4Shell (CVE-2021-44228) showed that companies with continuous scanning identified exposure in hours; those without monitoring took weeks. The scan is, therefore, the minimum floor of visibility.

Hiring a pentest makes sense in at least four situations: (1) before launching a new product or system into production; (2) after significant architectural changes — cloud migration, integration of third-party APIs, reworking of authentication; (3) as a compliance requirement — PCI DSS, ISO 27001, SOC 2, and sector regulations such as the Central Bank circulars for fintechs require periodic pentesting; (4) when your company processes sensitive data and needs to demonstrate due diligence to insurers, corporate clients, or boards.

Combining the two into a structured offensive-security program is what distinguishes mature companies from reactive ones. The scan ensures no asset goes blind between pentest cycles; the pentest validates whether the controls you deployed based on the scan results actually work against a human adversary. Companies operating only with scans accumulate lists of unprioritized CVEs. Companies operating only with an annual pentest stay blind for 11 months. Those that combine the two have a measurable continuous-improvement cycle.

The mistake that costs dearly: confusing a scan with a pentest

The most common misunderstanding in the Brazilian market is presenting a vulnerability scan report as evidence of a pentest for compliance or due-diligence purposes. PCI QSA auditors, ISO 27001 reviewers, and the security teams of large clients spot that difference immediately — and the consequence is non-conformity, failure in vendor-approval processes, or invalidation of cyber-insurance policies.

The root of the problem is commercial: some companies sell 'security reports' at prices well below the pentest market, delivering in practice an automated scan with a customized cover. The report has hundreds of pages, looks technical, but contains no evidence of real exploitation. If the document does not describe an attack chain, has no screenshots of compromised data or shells obtained, and does not demonstrate business impact, it is not a pentest — regardless of the commercial name used.

Before hiring, always ask for: the methodology used (PTES, OWASP Testing Guide, NIST 800-115), the résumé and certifications of the professionals who will perform the work (OSCP, CEH, CRTE, GPEN), and an anonymized example of the final report. Those three elements distinguish a real pentest from a repackaged scan.

Compliance and market cost ranges

For companies subject to PCI DSS 4.0, the requirements are explicit and not interchangeable: Requirement 11.3.2 requires quarterly external vulnerability scans by an Approved Scanning Vendor (ASV); Requirement 11.4 requires an annual pentest conducted by a qualified professional, with a retest after remediation of critical flaws. Presenting only one of the two results in non-conformity in the ROC or SAQ report.

For companies aligned with ISO 27001:2022, the standard does not prescribe an exact frequency, but Control 8.8 (technical vulnerability management) and Control 8.9 (configuration management) are frequently met with the combination of continuous scanning and periodic pentesting. Organizations in the certification process find that external assessors expect evidence of both practices.

In terms of market cost in Brazil in 2026: external vulnerability scanning for up to 50 IPs costs between R$ 500 and R$ 2,000/month on SaaS platforms; for 200+ IPs with web-application coverage, between R$ 3,000 and R$ 8,000/month. A web-application pentest (single scope, gray-box, up to 80 hours) starts at R$ 12,000; a corporate-infrastructure pentest with multiple segments and an executive report can range from R$ 35,000 to R$ 80,000 or more. Continuous red-team programs — which combine the two approaches in quarterly cycles — start at R$ 150,000/year for medium-sized companies.

Key terms

CVSS

Common Vulnerability Scoring System — a standardized system for scoring the severity of vulnerabilities on a scale of 0 to 10, maintained by FIRST. Scanners use CVSS to prioritize alerts, but the score does not consider the context of the analyzed environment.

CVE

Common Vulnerabilities and Exposures — a unique identifier for each publicly known vulnerability, in the format CVE-YEAR-NUMBER. Scanners compare the environment's characteristics against the CVE database to detect exposures.

ASV

Approved Scanning Vendor — a company accredited by the PCI Security Standards Council to perform the external vulnerability scans required by PCI DSS. Only ASV reports are accepted as proof of Requirement 11.3.2.

PTES

Penetration Testing Execution Standard — an open methodology describing the phases of a pentest: reconnaissance, threat modeling, vulnerability identification, exploitation, post-exploitation, and reporting. It is one of the references that distinguish a real pentest from a repackaged scan.

How to decide and hire well

1. Establish continuous visibility with automated scanning. Contract or deploy a vulnerability-scanning solution that covers all external assets (IPs, domains, APIs) and runs sweeps at least weekly, preferably daily. Configure alerts for new critical CVEs (CVSS ≥ 9.0) with immediate notification to the security team.
2. Define the scope and frequency of the pentest. Map the most critical systems: applications that process financial or personal data, internet-facing APIs, authentication infrastructure. Set pentest cycles — at least annual for compliance, semiannual for constantly changing environments — and document scope, rules of engagement, and emergency contacts in a formal Rules of Engagement.
3. Use the scan results to prioritize the pentest scope. The highest-CVSS, highest-exposure findings identified by the scan are the natural candidates for manual validation in the pentest. This keeps the pentester from spending hours on trivial surfaces and concentrates the human work time where the potential risk is greatest, maximizing return on investment.
4. Execute the pentest and document exploitation evidence. Conduct the pentest with a certified professional (OSCP, GPEN, or equivalent) following a documented methodology (PTES or OWASP Testing Guide). Require a report with a narrated attack chain, screenshots of real exploitation, demonstrated business impact, and remediation recommendations prioritized by actual risk — not by theoretical CVSS.
5. Remediate, validate with a retest, and update the scan baseline. After receiving the pentest report, fix the confirmed vulnerabilities in order of real-impact criticality. Request a retest of the critical flaws to confirm effective remediation. Update the scanner's rules and policies to reflect the newly deployed controls and monitor whether the fixes remain stable over time.
6. Integrate the cycles into a continuous offensive-security program. Document the results of each cycle in a centralized vulnerability register with mean-time-to-remediate (MTTR) metrics by severity. Use that metric to demonstrate maturity to auditors, corporate clients, and insurers. Schedule the next pentest cycle at least 60 days in advance to ensure the availability of a qualified professional and an adequate execution window.

Frequently asked questions

References

• ›OWASP Testing Guide v4.2 — The reference methodology for web-application security testing, covering more than 90 categories of manual tests organized by phase of the development cycle.
• ›NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment — The NIST technical guide that defines methodologies, techniques, and procedures for security testing, including review, target identification, vulnerability analysis, and penetration testing.
• ›CVSS v3.1 Specification Document — FIRST — The official specification of the Common Vulnerability Scoring System version 3.1, detailing the base, temporal, and environmental metrics used to score vulnerabilities.
• ›PCI DSS v4.0 Requirements and Testing Procedures — PCI SSC — The official document of the PCI DSS 4.0 requirements, including Requirements 11.3 (vulnerability scanning) and 11.4 (penetration testing) with the evidence criteria accepted for audit.