A vulnerability assessment can return a long list of findings and still miss the flaw that lets one customer read another customer’s records, because a scanner matches known weaknesses and does not sign in as two people. Pen test vs vulnerability assessment is that gap: a tool listing against a person proving, inside an agreed scope, the line NIST SP 800-115 draws.
What we are comparing, and for whom: seven names with different outputs
The set is seven names with different outputs. A vulnerability scan is the automated check; a vulnerability assessment adds a person’s review. A penetration test is people proving what works inside an agreed scope. A red team chases one goal, a bug bounty pays per finding, ethical hacking is the umbrella, and an audit checks controls against criteria.
This page is for whoever is holding a report, a quote or a questionnaire row with one of these words on it and needs the words straight before replying. Which of them a customer’s request actually means is sorted in scan, code audit, penetration test or certification, and if the real question is do I need a pen test at all, the request wordings are read there. The controls these tests probe are laid out under web app security.
The definitions below are quoted from NIST’s glossary, and the comparisons come from NIST SP 800-115 and the PCI Security Standards Council’s guidance, not from an engagement of mine. Where the glossary has no entry, the cell says so and the section defines the term in my words.
| Name | NIST’s glossary definition | Compared in |
|---|---|---|
| Vulnerability scan | ”A technique used to identify hosts/host attributes and associated vulnerabilities.” | Penetration testing vs vulnerability scanning |
| Vulnerability assessment | ”Systematic examination of an information system or product to determine the adequacy of security measures, identify security deficiencies”, among other aims | Pen test vs vulnerability assessment |
| Penetration test | ”A test methodology in which assessors, typically working under specific constraints, attempt to circumvent or defeat the security features of a system.” | Pen test vs vulnerability assessment |
| Red team | ”A group of people authorized and organized to emulate a potential adversary’s attack or exploitation capabilities against an enterprise’s security posture.” | Red team vs pentest |
| Bug bounty | ”A method of compensating individuals for reporting software errors, flaws, or faults” that might allow for exploitation | Bug bounty vs pentest |
| Ethical hacking | Not in NIST’s glossary | Ethical hacking and penetration testing |
| Audit | ”Independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established policies and operational procedures.” | Assessment versus audit |
Pen test vs vulnerability assessment: a person proving against a tool listing
Pen test vs vulnerability assessment is proof against a list. A vulnerability assessment runs tools, removes false positives and ranks known weaknesses. A penetration test puts people on an agreed scope for a set time to show which weaknesses can actually be used, and to find the logic and access-control flaws a tool has no signature for.
NIST SP 800-115, NIST’s technical guide to security testing published in September 2008, states the difference between vulnerability assessment and penetration testing this way: “While vulnerability scanners check only for the possible existence of a vulnerability, the attack phase of a penetration test exploits the vulnerability to confirm its existence.” The same guide says scanners “are unable to detect vulnerabilities that are revealed only as the result of potentially unending combinations of attack patterns”, and that assessors should determine the appropriate risk level for each vulnerability rather than simply accept the one a scanner assigns. That is the case for a person in the loop: a pen test report answers “can this be used?”, and a vulnerability assessment answers “what known weaknesses might be here?”
The PCI Security Standards Council’s penetration testing guidance (version 1.1, September 2017) sets a vulnerability scan beside a penetration test, row by row, as PCI DSS requires them. In my reading the scan column is the automated core of a vulnerability assessment, so the table below uses it for that side. The first five rows are the guidance’s, shortened; the last two are my reading, not the guidance’s.
| Vulnerability scan (the core of an assessment) | Penetration test | |
|---|---|---|
| Purpose | Identify, rank and report vulnerabilities that, if exploited, may result in a compromise of a system | Identify ways to exploit vulnerabilities to circumvent or defeat the security features of system components |
| When, under PCI DSS | At least quarterly and after significant changes | At least annually and upon significant changes |
| How | Typically a variety of automated tools combined with manual verification of identified issues | A manual process that may include vulnerability scanning or other automated tools, resulting in a comprehensive report |
| Reports | Potential risks posed by known vulnerabilities, ranked by NVD/CVSS base scores | Each vulnerability verified or potential issue discovered, with specific methods how and to what extent it may be exploited |
| Duration | Typically several seconds to several minutes per scanned host | May last days or weeks, depending on the scope of the test and the size of the environment |
| False positives (my reading) | Expected in the list; a person removes them before the report | Removed by proof: a finding is shown to work, or labeled as unproven |
| What it needs from you (my reading) | A target list | An agreed scope, test accounts and signed authorization from the system’s owner |
In 3 of the 21 third-party apps, scanners flagged 33 to 44 vulnerabilities and the audit traced exactly zero as reachable. In the other direction, 7 of the 21 third-party apps had confirmed cross-user or cross-tenant authorization failures, where a logged-in user could read or write another customer’s data. Those 21 are the 11 public third-party apps and the 10 held-out third-party apps I audited in June and July 2026: a selected set of audited apps, not a random sample and not a rate for all apps. My reading of the two numbers together: a person signed in with two accounts finds the second kind, and a scanner’s list does not name it.
One public advisory shows the shape of that second kind: backend endpoints that only check whether the caller is logged in, not whether the caller has backend or administrative privileges, which I read as exactly the flaw a person proves with two accounts; the admin panel security checklist is a separate subject.
Vulnerability testing and a vulnerability test are loose names for the same assessment, so a pen test vs vulnerability test question, or penetration testing vs vulnerability testing, is this comparison under another label. Whether one CVE on a scanner’s list actually reaches your code is a separate job: how to detect log4j vulnerability in your dependencies.
Penetration testing vs vulnerability scanning: where the scan sits inside both
Penetration testing vs vulnerability scanning is a whole job against one step inside it. The scan is the automated check. An assessment is the scan plus a person ranking the results. A pen test usually starts with a scan and goes on where the scan stops. A report holding only scanner output is a scan, whatever its title says.
NIST SP 800-115 describes that order: “penetration testing usually relies on performing both network port/service identification and vulnerability scanning to identify hosts and services that may be targets for future penetration.” It also calls vulnerability scanning “a somewhat labor-intensive activity that requires a high degree of human involvement to interpret results”, which is the step that turns a vulnerability scan into an assessment.
So a vulnerability scan and a pen test on one invoice are two line items, and the difference between penetration testing and vulnerability scanning shows up in the report: a pentest vs vulnerability scan comparison is settled by whether any finding carries proof that it worked. That last test is my reading, not NIST’s.
What each kind of scanner checks and misses is covered by the vibe coding security scanner guide on this blog. The scan types themselves (static, dynamic, dependency) and which ones a small team should run are compared in SAST vs DAST, and tools that keep findings tracked over time are in vulnerability management tools.
Red team vs pentest: a goal against a scope
Red team vs pentest is a goal against a scope. A pen test looks for everything wrong inside an agreed target while the defenders usually know of it. A red team exercise tries to reach one objective by any agreed route and tests detection and response. A company with nobody watching alerts has nothing for a red team to measure.
NIST’s glossary describes a red team as a group “authorized and organized to emulate a potential adversary’s attack or exploitation capabilities”, whose objective includes “demonstrating what works for the defenders (i.e., the Blue Team)”. NIST’s definition of a red team is about the defenders as much as the attack. A pen test can touch detection too, since SP 800-115 lists “Defenders’ ability to detect attacks and respond appropriately” among the things penetration testing can be useful for determining, but the pen test’s question stays narrower: what is wrong with this application inside this scope?
The table is my reading of how the two differ in practice, not a quote from either source.
| Pen test | Red team exercise | |
|---|---|---|
| Objective | Find what is wrong in the agreed targets | Reach one agreed goal, and see whether anyone notices |
| Scope | Named applications, hosts or accounts | People, process and technology, within agreed limits |
| Who knows it is happening | The team that owns the system, usually | Few people, often only those who approved it |
| Duration | A fixed window set in the agreement | Usually longer, because staying unnoticed takes time |
| Output | Findings with evidence, then a retest | The route taken, and what the defenders saw or missed |
| Who it suits | Any team that ships an app and needs its flaws found | A company with people watching alerts and responding |
Whether a form asks for a red team pentest or for redteam pentesting, the question underneath is the same: do you want your flaws listed with proof, or your detection tested? For a small company without a security team, my reading is that a pentest vs red team choice lands on the pen test, because a red team exercise presumes someone on alert duty. Searches for pen testing teams are after a different split, red, blue and purple teams, and those definitions sit in the web application penetration testing guide.
When a customer’s form says “red team”, my working rule is to ask what they want tested before quoting anything. If they want the flaws in the app found, that is a penetration test; if they want to know whether anyone on their side notices an attack, that is a red team exercise. Settling pentesting vs red teaming that way comes before any price, and it keeps a vague “pen test red team” line item off the quote. The request wordings themselves are read in the pen test article linked above.
Bug bounty vs pentest: paying per finding against paying for coverage
Bug bounty vs pentest is paying per finding against paying for coverage. A pen test covers a defined scope in a defined period and ends in a report a reviewer can read. A bug bounty runs continuously and pays outside researchers for each valid finding, with no promise that any given feature was looked at.
NIST’s glossary entry, quoted in the table at the top, defines a bug bounty by how people are paid, not by what they cover. That is the practical line. A bounty can surface a flaw nobody on a test thought to try, and a test can promise that the sign-in flow, the billing pages and the admin routes were each looked at by someone. They answer different worries.
A reviewer who asked for a pen test report gets that report from a test, not from a bounty: there is no single document at the end of a bounty that says what was covered and when. That is my reading of the two models, not a rule from a standard. What a bounty is, when one makes sense for a small company, and the disclosure contact that comes before it are a separate subject, starting from a security.txt file example.
Ethical hacking and penetration testing: a field, and one job inside it
Ethical hacking and penetration testing overlap, and the second sits inside the first. Ethical hacking is any authorized attempt to find weaknesses, from research to bounty hunting. Penetration testing is one job within it, set by a contract, a scope, a time box and a report. Written authorization from the system’s owner is what makes either one legitimate.
So ethical hacking vs penetration testing is a field against a job. An ethical hacker and a penetration tester may be the same person on different days: hunting bounties on Monday, working a scoped test under contract on Tuesday. Every pentester working under contract is doing ethical hacking; not every ethical hacker is running pen tests.
Certifications carry the same split in their names: EC-Council’s Certified Ethical Hacker (CEH), and OffSec’s OSCP, which OffSec now spells out as OffSec Certified Professional. My working rule for a buyer is to ask for a sample report and the methodology before asking for certificates. For web apps the public methodology a test can be held to is OWASP’s Web Security Testing Guide, which OWASP describes as a testing resource for web application developers and security professionals; v4.2 is the current release, with version 5.0 in development.
Written authorization from the owner of the system is what separates any of this from an attack, whatever the tester calls themselves. This page is not legal advice; test only systems you own or have written permission to test.
Assessment versus audit, and security testing vs penetration testing
Assessment versus audit is advice against an opinion. An assessment asks how secure something is and ends in recommendations that inform decisions. An audit is an independent examination of whether controls meet named criteria, and it ends in a conclusion on them. A pen test is one kind of evidence an auditor may read; it is not itself an audit.
NIST’s glossary words it this way. An assessment is “An evidence-based evaluation and judgement” whose note says assessments “are generally informational in nature and used to support decision making and to inform formal inspections or audits.” An audit, in the definition NIST takes from ISO, is a “Systematic, independent and documented process for obtaining audit evidence and evaluating it objectively to determine the extent to which the audit criteria are fulfilled.” NIST’s definition of an audit lists more than one source; the independence runs through each. What “security assessment” means on its own, as a service name, is a separate question, closer to a security review.
| Assessment | Audit | Penetration test | |
|---|---|---|---|
| The question it answers | How sound is this, and what should change? | Do the controls meet the stated criteria? | What can someone actually do against these targets? |
| Measured against | The assessor’s evidence and judgment | Audit criteria, policies and procedures | The agreed scope and rules of engagement |
| The output | Findings and advice that support decisions | A conclusion on how far the criteria are fulfilled | Verified findings with evidence, and a retest |
SOC 2 is one audit a software company may be asked about. The AICPA describes its SOC reports as “a suite of service offerings CPAs may provide”, and its SOC 2 guide is titled as reporting on an examination of controls at a service organization. So pen test vs security audit is a part against a whole: the auditor decides which evidence to examine, and a pen test report may be one piece of it.
Security assessment vs security audit follows the same line as the table: advice against an opinion on named criteria. Security testing vs penetration testing is a family against one member: the family covers scans, code reviews and functional security tests, and pen testing is the member where a person tries to break in. That grouping is my reading. PCI DSS sets its own testing rules for card data, covered in PCI DSS penetration testing. Which of these a contract or a regulation requires depends on the contract and the jurisdiction, and this page is not legal advice.
How to check what you were given: six marks of a real pen test report
A real pen test report has six marks: a scope with targets, dates and test accounts, a named methodology and named testers, findings with evidence specific to your app, a tested statement on access between two users, severity with reasoning, and a retest section. A document missing the third and fourth marks is a vulnerability assessment with a cover page.
Each mark can be checked on the document in hand, and each has a page or section where it shows or does not.
- 01 A scope section that names the targets, the test dates, the test accounts used and what was out of scope. Check: the section exists and names your app, not a generic domain
- 02 A named methodology, such as OWASP's testing guide or an equivalent, and the names of the testers. Check: both appear, not only a company logo
- 03 Findings with reproduction evidence specific to your app: requests, screenshots, records in a test account. Check: at least one finding shows your own screens or data, not a scanner's generic description
- 04 At least one finding, or an explicit tested-not-vulnerable statement, on access between two users. Check: the report says which two accounts were used and what one tried to read of the other's
- 05 Severity with reasoning, not only a tool's score. Check: each high finding says why it matters for this app
- 06 A retest section showing which fixes were verified and when. Check: dates and results per finding, after the original test
The marks are my working rule for a buyer, not a standard. They line up with the PCI guidance’s own report outline, which lists a statement of scope, a statement of methodology and findings with a risk ranking; when findings need remediation and retesting before an assessor can confirm the requirement is met, the guidance says a follow-up test report may be provided, and its example sections include the date of the original test and the date of the retest. The same guidance asks for authenticated testing on multitenant apps “to ensure customer access is properly restricted to only their own cardholder data”, which is mark four in card-data terms.
The evidence levels a finding can reach, and the questions to ask a provider before buying, are in the pen test article already linked. The full report layout, the scope agreement and what to do with the findings are in the penetration test report format. Running a test on a web app is covered in web application penetration testing, and what one costs and how to buy it in affordable penetration testing.
Where the sprint fits
In the Production Hardening Sprint, deliverable 3.10 is to “Test the five highest-risk externally reachable attack surfaces, remediate findings, and deliver the methods and evidence.” That deliverable is verified this way: “Record the five surfaces, authorized tests, findings, fixes, and retest outcomes. AxonBuild performs this targeted test.” Beside it, 3.7 is to “Review the application against the OWASP Top 10 and record findings, fixes, and evidence by category”, and 3.5 is to “Audit dependencies, upgrade or remove known-vulnerable packages, and remove unused packages.” Formal third-party certifications and independent audit opinions are separate from the sprint deliverables, so a contract that requires an independent third-party test needs a tester from outside the team that did the work. Every deliverable, with how each is verified, is listed in the published scope.
Common questions about security testing names
What are the two main types of vulnerability scans?
The two splits the sources draw are external against internal, and with credentials against without. The PCI guidance says an external vulnerability scan is conducted from outside the target organization and an internal one from inside it. NIST SP 800-115 describes scanners that hold administrator-level credentials on the hosts they scan and scanners that do not, and says internal scanning usually uncovers more vulnerabilities than external scanning, though testing from both viewpoints is important.
In everyday use, a scan run with credentials is what people mean by an authenticated scan.
What are the key differences between a DAST scan and a pentest?
A DAST scan is a tool probing a running web app for known patterns; a pen test is people working inside an agreed scope for a set time, who also cover the logic and access-control flaws a tool has no signature for. The scan is fast and repeatable; the test proves which findings can actually be used. That split is my reading. DAST on its own is compared with SAST in the scan types article in this series.
Is pentesting blue or red team?
Pentesting is offensive work, so it sits on the red side by skill. It differs from a red team exercise in that a pen test is announced and scoped, while a red team exercise also tests whether the defenders detect and respond. That is my reading; the full red, blue and purple team definitions are in the web application penetration testing guide.
What is the difference between VAPT and pen testing?
VAPT is a label for a vulnerability assessment and a penetration test sold together. The label does not tell you how much of the work is each half. Check the report against the six marks above: a VAPT report that fails the evidence and two-user marks contains the assessment half only. That reading is mine.
Are auditor and assessor the same thing?
No. NIST’s glossary defines an assessor as “The individual, group, or organization responsible for conducting a security or privacy assessment”, while its audit entries describe an independent examination against audit criteria; it has no general entry for auditor. In practice an assessor evaluates and advises, and an auditor checks against criteria and concludes.
The checks in this guide show you where the app is open. The sprint below closes those gaps, tests the result and writes the evidence down.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase